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Steve Souders 推 荐 序 


“合格 的 开发 者 知道 怎么 做 ， 而 优秀 的 开发 者 知道 为 什么 那么 做 。 


相信 每 一 位 读者 看 完 这 句 话 ， 一 定 打 心眼 儿 里 赞同 。 我 们 都 希望 自己 能 够 理解 身边 
的 各 种 系统 ， 同 时 还 能 跟 别人 讲 得 明白 。 然 而 ， 如 果 你 是 一 名 Web 开发 者 ， 那 很 可 
能 距离 这 个 目标 会 越 来 越 远 。 


Web 开发 的 分 工 越 来 越 细 。 你 在 做 哪 一 类 Web 开发 ? 前端? 后 端 ? 运 维 ? 大 数据 
分 析 ? ULUX? 存储 ?视频 ?实时 消息 ?我 还 想 再 加 上 一 个 角色 一 一 性 能 工程 师 。 


钻研 基础 知识 与 紧 跟 最 新 动向 本 身 是 一 对 矛盾 ， 很 难 平衡 。 可 是 ， 没 有 基础 ， 那 只 
能 是 “ 墙 上 访 苇 ， 头 重 脚 轻 根 底 浅 "。 光 知道 表面 上 的 那 点 东西 可 不 行 。 需 要 解决 难 
题 时 ， 发 生 异 常 状况 时 ， 理 解 基础 知识 的 人 会 脱颖而出 。 


正 因为 如 此 ， 我 才 说 这 本 书 非 常 重要 ， 不 能 不 看 。 如 果 你 搞 的 是 Web 开发 ， 那 你 技 
术 体 系 的 根基 就 是 Web 和 它 赖 以 存在 的 大 量 网 络 协 议 : TCP、TLS、UDP、HTTP， 
等 等 。 这 些 协 议 分 别 有 各 自 的 性 能 特点 和 优化 技巧 ， 为 开发 高 性 能 应 用 ， 你 必须 理 
解 为 什么 网 络 那么 运行 。 


说 实话 ， 我 真 为 想 读 这 本 书 的 你 感到 庆幸 ! 要 是 我 刚刚 接触 Web 编程 时 有 这 样 一 本 
书 就 好 了 。 那 样 ， 就 会 有 一 位 真正 理解 网 络 的 人 为 我 释疑 解 惑 ， 告 诉 我 那些 标准 和 
规范 的 要 点 ， 填 充 我 技术 体系 中 的 空白 。 这 本 书 的 作者 IHya Grigorik， 是 少见 的 网 
络 编程 专家 ， 而 本 书 堪 称 实战 经 验 与 规范 解读 完美 结合 的 产物 。 


本 书 中 ， 作 者 解释 了 网 络 编程 中 的 很 多 为 什么 : 为 什么 延迟 是 性 能 瓶颈 ? 为 什么 
TCP 并 不 总 是 最 优 传输 机 制 ， 而 UDP 有 时 候 反 而 是 更 好 的 选择 ? 为 什么 重用 连接 
是 关键 性 的 优化 策略 ?然后 ， 他 又 更 进一步 ， 给 出 改进 网 络 性 能 的 具体 建议 。 想 要 
降低 延迟 ?在 靠近 客户 端的 服务 器 上 完成 会 话 。 想 要 提高 连接 重用 率 ? 保持 连接 持 
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入 化 。 正 是 这 种 提出 问题 、 分 析 问 题 和 解决 问题 的 模式 ， 让 本 书 内 容 极 为 贴近 实战 ， 
接地 气 。 


除了 全 面 探 讨 网 络 的 基础 知识 ， 作 者 还 详细 讲解 了 协议 和 浏览 器 的 最 新 进展 。 讲 
了 HTTP 2.0 的 诸多 优点 ， 回 顾 了 XHR 及 其 催生 CORS (Cross-Origin Resource 
Sharing， 跨 源 资源 共享 ) 的 局 限 性 ， 还 有 SSE (Server-Sent Events， 服 务 器 发 送 事 
件 )、WebSockets 和 WebRTC。 让 我 们 彻底 跟 上 了 浏览 器 网 络 技术 栈 的 最 新 进展 。 


从 性 能 角度 分 析 ， 基 础 和 最 新 进展 是 本 书 特色 ， 也 是 本 书 贯 穿 始终 的 主线 。 正 是 性 能 
这 个 视角 ， 让 我 们 理解 了 网 络 开 发 中 的 那么 多 为 什么 ， 明 白 了 这 些 东 西 怎 么 影响 我 们 
的 网 站 和 用 户 。 本 书 把 抽象 的 规范 变 成 了 可 操作 的 建议 ， 让 我 们 可 以 马上 学 以 致 用 去 
优化 网 站 ， 去 创造 最 佳 用 户 体验 。 这 才 是 最 重要 的 。 所 以 ， 一 定 不 要 错过 这 本 书 ! 








一 一 Steve Souders 
世界 级 Web 性 能 专家 、 人 谷歌 公司 高 性 能 工程 师 
《高 性 能 网 站 建设 指南 》 等 畅销 书 作 者 ，2013 








注 1: 2014 年 3 月 ，Steve Souders 加 入 国际 知名 云 加 速 平 台 Fastly， 任 首席 性 能 官 。 一 一 编者 注 
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es i ep ert eat ap ?能 手机 ， 
一 台 平 板 、 笔 记 本 和 桌面 电脑 ， 以 及 介 于 这 些 之 间 的 其 他 设备 ， 都 安装 了 Web 浏览 
据 预 测 ， 到 2020 年 ， 能 上 网 的 设备 将 突破 200 亿 部 ， 其 中 每 一 部 都 会 安装 浏览 
， 而 且 最 低 限 度 都 会 支持 Wi-Fi 或 蜂窝 连接 。 至 于 运行 的 是 什么 平台 ， 设 备 是 谁 制 
ee 都 无 所 请， 反正 每 部 设备 都 会 带 一 个 浏览 器 。 就 是 这 个 
浏览 器 ， 它 的 功能 正 变 得 越 来 越 强大 。 


回首 从 前 ， 那 时 的 浏览 器 与 现在 我 们 使 用 的 浏览 器 完全 不 能 同日 而 语 。 浏 览 器 革命 还 
是 最 近 几 年 的 事 : HTML 和 CSS 构成 表现 层 ，JavaScript 则 成 为 Web 上 的 新 “汇编 ” 
语言 ， 而 新 的 HTML5 API 仍 在 不 断 改 进 ， 致 力 于 为 交付 吸引 人 的 高 性 能 应 用 提供 新 
功能 。 可 以 说 ， 有 史 以 来 还 没有 哪 项 技术 或 平台 ， 在 部 署 或 装机 率 方面 能 和 今天 的 浏 
览 刀 相提并论。 所 以 ， 这 里 有 无 限 的 机 会 ， 创 新 也 无 处 不 在 。 


而 且 ， 浏 览 器 中 网 络 基 础 设施 的 快速 发 展 与 创新 ， 同 样 是 天 下 无 敌 。 过 去 ， 我 们 能 实 

现 的 交互 仅 限 于 简单 的 HTTP 请 求 和 响应 ;， 如今， 高 效 的 流 式 传输 、 双 向 实时 通信 ， 

nn 甚至 端 到 端 视频 会 议和 两 端 避 之 间 直 接 交换 数据 ， 都 已 经 成 为 现 
。 而 且 ， 所 有 这 些 只 不 过 是 几 十 行 JavaScript 代码 的 事 儿 。 


然后 呢 ?” 儿 十 亿 设 备 互联 ， 已 有 和 新 在 线 服务 吸引 的 用 户 越 来 越 多 ， 只 有 高 性 能 Web 
应 用 才 谈 得 上 竞争 力 。 速 度 是 关键 | 事实 上 ， 对 某 些 应 用 来 说 ， 速 度 决定 命运 。 要 开发 
出 高 性 能 的 Web 应 用 ， 必 须 透彻 理解 浏览 器 及 其 网 络 交互 机 制 ， 而 这 正 是 本 书 的 主题 


关于 本 书 


本 书目 标 是 涵盖 开发 者 应 该 掌握 的 所 有 网 络 知识 : 网 络 开发 中 要 用 到 哪些 协议 ， 这 些 
协议 有 什么 固有 的 局 限 性 ， 如 何 针对 底层 网 络 优化 自己 的 应 用 ,浏览 器 提供 了 哪些 网 
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络 相 关 的 功能 ， 以 及 什么 时 候 需 要 用 到 它们 。 


我 们 将 从 TCP、UDP 和 TLS 协议 的 内 部 工作 原理 讲 起 ， 向 大 家 解释 如 何 针 对 这 几 种 
协议 和 基础 设施 来 优化 我 们 的 应 用 。 然 后 深入 地 探讨 无 线 和 移动 网 络 的 工作 机 制 ， 以 
无 线 电 为 媒介 的 通信 可 大 不 一 样 。 对 此 ， 我 们 将 围绕 如 何 设 计 和 架构 应 用 ， 讨 论 它 们 
各 自 的 痛 点 所 在 。 最 后 ， 我 们 再 揭示 HTTP 协议 的 底层 细节 ， 同 时 详细 介绍 浏览 器 新 
增 的 一 些 令 人 激动 的 能 


。 即将 到 来 的 HTTP 2.0 的 诸多 改进 ， 

。 XHR 的 新 特性 和 新 功能 ， 

。 通过 SSE 发 送 数 据 流 ，; 

。 通过 WebSocket 实现 双向 通信 ; 

。 通过 WebRTC 实现 端 到 端的 音频 和 视频 通信 ， 
。 通过 DataChannel 实现 端 到 端的 数据 交换 。 





















































要 设计 和 开发 高 性 能 的 应 用 ， 必 须 理 解 每 一 位 数据 是 如 何 交 付 的 ， 必 须 理解 每 一 种 传 
输 机 制 和 相关 协议 的 特点 。 毕 竞 ， 等 待 网 络 是 我 们 应 用 最 大 的 性 能 瓶颈 ， 再 怎么 优化 
泻 染 JavaScript 或 其 他 方面 ， 也 抵 不 上 网 络 优化 ! 本 书 的 目标 就 是 告诉 读者 怎么 消除 
等 待 时 间 ， 利 用 现 有 网 络 实现 最 大 的 性 能 优化 。 


本 书 全 面 介绍 了 Web 性 能 优化 的 知识 和 技术 ， 适 合 对 构建 和 交付 高 性 能 应 用 感 兴趣 的 
所 有 读者 。 简 单 地 说 ， 如 果 你 不 满足 于 那些 枯燥 的 检查 表 ， 而 更 希望 知晓 浏览 器 乃至 
底层 协议 的 真实 工作 过 程 ， 就 应 该 读 一 读 这 本 书 。 本 书 既 会 对 配置 和 架构 给 出 实用 建 
议 ， 也 会 探讨 为 达成 优化 目标 而 必须 考虑 的 因素 和 权衡 的 要 点 ， 既 讲 “ 怎 么 办 "， 也 
讲 “ 为 什么 ”。 








地 3 
和 本 书 重点 讨论 与 浏览 器 应 用 相关 的 各 种 协议 及 特性 。 不 过 ， 关 于 TCP、 
心 。UDP、TLS、HTTP， 乃 至 其 他 每 一 种 协议 的 讨论 ， 同 样 也 适用 于 本 地 应 


人 


”用 ， 而 且 不 局 限于 任何 平台 。 

















排版 约定 
本 书 使 用 的 排版 约定 如 下 。 


， 楷 


表示 新 的 术语 。 





六 








。 等 宽 字体 
表示 程序 片段 ， 也 用 于 在 正文 中 表示 程序 中 使 用 的 变量 、 函 数 名 、 命 令 行 代码 、 
环境 变量 、 语 句 和 关键 词 等 代码 文本 。 
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。 加 粗 的 等 宽 字 体 
表示 应 该 由 用 户 逐 字 输 入 的 命令 或 者 其 他 文本 。 

。 倾斜 的 等 宽 字 体 
表示 应 该 由 用 户 输入 的 值 或 根据 上 下 文 决 定 的 值 替 换 的 文本 。 


培 sa， 


ax 这 个 图 标 代表 小 穿 门 、 建 议 或 说 明 。 











一 E> 这 个 图 标 代表 警告 信息 





Safari2 Books Online 


eo0> Safari Books Online (www.safaribooksonline.com) 是 应 
Gafarl 需 而 变 的 数字 图 书馆 。 它 同时 以 图 书 和 视频 的 形式 出 版 
Books Online” 世界 顶级 技术 和 商务 作家 的 专业 作品 。 
Safari Books Online 是 技术 专家 、 软 件 开 发 人 员 、Web 设计 师 、 商 务 人 士 和 创意 人 
士 开 展 调研 、 解 决 问 题 、 学 习 和 认证 培训 的 第 一 手 资料 。 
对 于 组 织 团 体 、 政 府 机 构 和 个 人 ，Safari Books Online 提供 各 种 产品 组 合 和 灵活 
的 定价 策略 。 用 户 可 通过 一 个 功能 完备 的 数据 库 检 索 系 统 访问 OReilly Media、 


Prentice Hall Professional、 Addison-Wesley Professional、 Microsoft Press、 Sams、 











Que、Peachpit Press、 Focal Press、 Cisco Press、 John Wiley & Sons、 Syngress.、 
Morgan Kaufmann、IBM Redbooks、Packt、Adobe Press、 FT Press、 Apress.、 
Manning、New Riders、McGraw-Hill、Jones & Bartlett、Course Technology 以 及 其 他 
几 十 家 出 版 社 的 上 千 种 图 书 、 培 训 视 频 和 正式 出 版 之 前 的 书稿 。 要 了 解 Safari Books 
Online 的 更 多 信息 ， 我 们 网 上 见 


联系 我 们 


请 把 对 本 书 的 评价 和 问题 发 给 出 版 社 。 





美国 : 
O’Reilly Media, Inc. 
1005 Gravenstein Highway North 


Sebastopol, CA 95472 
区 西直门 南大 街 2 号 成 馈 大 厦 C 座 807 室 (100035) 











中 国 : 
北京 市 西城 

奥 羔 利 技术 咨询 (北京 ) 有 限 公 司 
都 有 专属 网 页 ， 你 可 以 在 那儿 找到 本 





O’Reilly 的 每 一 本 


表 、 示 例 代码 以 及 其 他 信息 。 本 书 的 网 站 地 址 是 : 
http://shop.oreilly.com/product/0636920028084.do 


bookquestions @oreilly.com 
品 





要 了 解 更 多 O’Reilly 图 


http://www.oreilly.com 


我 们 在 Facebook 的 地 址 如 下 : 


http://facebook.com/oreilly 


请 关注 我 们 的 Twitter 动态 : 
http://twitter.com/oreillymedia 


我 们 的 YouTube 视频 地 址 如 下 : 
http://www.youtube.com/oreillymedia 


区 的 相关 信息 ， 包 括 勘 误 


对 于 本 书 的 评论 和 技术 性 问题 ， 请 发 送 电 子 邮 件 到 : 
书 、 培 训 课 程 、 会 议和 新 闻 的 信息 ， 请 访问 以 下 网 站 : 





第 一 部 分 





网 络 技术 概观 





1.1 速度 是 关键 


近 几 年 来 ，WPO (Web Performance Optimization，Web 性 能 优化 ) 产业 从 无 到 有 ， 
快速 增长 ， 充 分 说 明 用 户 越 来 越 重视 速度 方面 的 用 户 体验 。 而 且 ， 在 我 们 这 个 节奏 
越 来 越 快 、 联 系 越 来 越 紧密 的 世界 ， 追 求 速度 不 仅仅 是 一 种 心理 上 的 需要 ， 更 是 一 





种 由 现实 事例 驱动 的 用 户 需求 。 很 多 在 线 公司 的 业绩 已 经 证 实 : 
风 站 越 快 ， 用 户 的 黏 性 越 高 ， 
站 越 快 ， 用 户 忠诚 度 更 高 ; 
网站 越 快 ， 用 户 转 化 率 越 高 。 





悦 司 习 


简 言 之 ， 速 度 是 关键 。 要 提高 速度 ， 必 须 先 了 解 与 之 相关 的 各 种 因素 ， 











的 限制 。 本 章 主要 介绍 对 所 有 网 络 通信 都 有 决定 性 影响 的 两 个 方面 : 
(图 1-1)。 











。 延迟 
分 组 从 信息 源 发 送 到 目的 地 所 需 的 时 间 。 
带宽 
逻辑 或 物理 通信 路 径 最 大 的 吞吐 量 。 


以 及 根本 性 
延迟 和 带宽 
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1-1: 延迟 和 带宽 


理解 了 带宽 和 延迟 之 间 的 关系 ， 接 下 来 就 可 以 进一步 探讨 TCP、UDP， 以 及 构建 于 
它们 之 上 的 所 有 应 用 层 协议 的 内 部 构造 和 性 能 特征 。 








为 减少 跨 大 西洋 的 延迟 而 铺设 Hibernia Express 专线 

在 金融 市 场 上 ， 很 多 常用 交易 算法 首要 的 考虑 因素 就 是 延迟 ， 因 为 几 ms 的 差距 可 
能 导致 数 百 万 美元 的 收益 或 损失 。 

2011 年 初 ， 华 为 与 Hibernia Atlantic 开始 合作 铺设 一 条 横 跨 大 西洋 ， 连 接 伦 敦 和 
纽约 的 近 5000 km 的 海底 光缆 (Hibernia Express) 。 铺 设 这 条 海底 光缆 的 唯一 目 
的 ， 就 是 减少 城市 间 的 路 由 ，( 相 对 于 使 用 其 他 横 跨 大 西洋 的 线路 ) 为 交易 商 节 
省 5 ms 的 延迟 。 开 通 运营 后 ， 这 条 光缆 将 只 由 金融 机 构 使 用 ， 耗资 预计 达 4 亿 
简单 计算 一 下 ， 不 难得 出 节省 1 ms 的 成 本 是 8000 万 美元 。 延 迟 的 代价 由 此 可 见 
一 班 。 











1.2 延迟 的 构成 

延迟 是 消息 (message) 或 分 组 (packet) 从 起 点 到 终点 经 历 的 时 间 。 这 个 定义 简单 明 
了 ,但 却 掩 盖 了 很 多 有 用 的 信息 。 事 实 上 ， 任 何 系 四 有 从 很 网 次 2] 引 有 吓 作 冰 说 
的 时 间 。 因 此 ， 和 弄 清 楚 这 些 因素 是 什么 ， 以 及 它们 如 何 影 响 性 能 是 最 重要 的 。 

下 面 看 看 路 由 器 这 个 负责 在 客户 端 和 服务 器 之 间 转 发 消息 的 设备 ， 会 牵涉 哪些 影响 
延迟 的 因素 。 
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。 传播 延迟 

消息 从 发 送 端 到 接收 端 需要 的 时 间 ， 是 信号 传播 距离 和 速度 的 函数 
。 传输 延迟 

把 消息 中 的 所 有 比特 转移 到 链 路 中 需要 的 时 间 ， 是 消息 长 度 和 链 路 速率 的 函数 
。 处 理 延 迟 

处 理 分 组 首部 、 检 查 位 错误 及 确定 分 组 目标 所 需 的 时 间 





。 排队 延迟 
到 来 的 分 组 排队 等 待 处 理 的 时 间 


以 上 延迟 的 时 间 总 和 ， 就 是 客户 端 到 服务 器 的 总 延迟 时 间 。 传 播 时 间 取 决 于 距离 和 
信号 通过 的 媒介 ， 另 外 传播 速度 通常 不 超过 光速 。 而 传输 延迟 由 传输 链 路 的 速率 决 
定 ， 与 客户 端 到 服务 器 的 距离 无 关 。 举 个 例子 ,假设 有 一 个 10 MB 的 文件 ， 分 别 通 
过 两 个 链 路 传输 ， 一 个 1 Mbits， 另 一 个 100 Mbit/s。 在 1 Mbit/s 的 链 路 上 ， 需 要 花 
10 s， 而 在 100 Mbit/s 的 链 路 上 ， 只 需 0.1 s。 




















接着 ， 分 组 到 达 路 由 器 。 路 由 器 必须 检测 分 组 的 首部 ， 以 确定 出 站 路 由 ， 并 且 还 可 
能 对 数据 进行 检查 ， 这 些 都 要 花 时 间 。 由 于 这 些 检查 通常 由 硬件 完成 ， 因 此 相应 的 
延迟 一 般 非常 得， 但 再 短 也 还 是 存在 。 最 后 ， 如 果 分 组 到 达 的 速度 超过 了 路 由 器 的 
处 理 能 力 ， 那 么 分 组 就 要 在 入 站 缓冲 区 排队 。 数 据 在 缓冲 区 排队 等 待 的 时 间 ， 当 然 
就 是 排队 延迟 。 

每 个 分 组 在 通过 网 络 时 都 会 遇 到 这 样 或 那样 的 延迟 。 发 送 端 与 接收 端的 距离 越 远 ， 
传播 时 间 就 越 长 。 一 路 上 经 过 的 路 由 器 越 多 ， 每 个 分 组 的 处 理 和 传输 延迟 就 越 多 。 
最 后 ， 网 络 流 量 越 拥 挤 ， 分 组 在 入 站 缓冲 区 中 被 延迟 的 可 能 性 就 越 大。 















































本 地 路 由 器 的 缓冲 区 爆满 
缓冲 区 爆满 (Bufferbloat) 是 Jim Gettys 在 2010 年 发 明 的 一 个 术语 ， 是 排队 延迟 
影响 网 络 整体 性 能 的 一 个 形象 的 说 法 。 
造成 这 个 问题 的 原因 主要 是 如 今 市 面 上 的 路 由 器 都 会 配备 很 大 的 入 站 缓冲 区 ， 以 便 
“不 惜 一 切 代 价 ” 避 和 免 丢 包 (分 组 ) 。 可 是 ， 这 种 做 法 破坏 了 TCP 的 拥塞 预防 机 制 
(congestion avoidance， 下 一 章 将 介绍 ) ， 导 致 网 络 中 产生 较 长 且 可 变 的 延迟 时 间 。 
为 解决 这 个 问题 ， 有 人 提出 了 新 的 CoDel 主动 队列 管理 算法 ， 且 已 经 在 Linux 内 
核 3.5 以 上 版 本 中 实现 。 如 果 想 了 解 更 多 内 容 ， 可 以 参考 ACM 的 一 篇 论文 ， 搜 索 
“Controlling Queue Delay” 就 能 找到 。 











1.3 光速 与 传播 延迟 


正如 爱 因 斯 坦 在 他 的 狭义 相对 论 里 所 说 的 ， 光 速 是 所 有 能 量 、 物 质 和 信息 运动 所 能 
达到 的 最 高 速度 。 这 个 结论 给 网 络 分 组 的 传播 速度 设 定 了 上 限 。 


好 消息 是 光速 极 快 ， 每 秒 能 达到 299 792 458 米 (大 约 30 万 公里 )。 但 是 ， 别 忘 了 
还 有 个 但 是 ， 这 是 光 在 真空 中 的 传播 速度 。 而 网 络 中 的 分 组 是 通过 铜 线 、 光 纤 等 介 
质 传播 的 ， 这 些 介质 会 导致 传播 速度 变 慢 。 光 速 与 分 组 在 介质 中 传播 速度 之 比 ， 叫 
做 该 介质 的 折射 率 。 这 个 值 越 大 ， 光 在 该 介质 中 传播 的 速度 就 越 慢 。 


传播 分 组 的 光纤 ， 大 多 数 折射 率 从 1.4 到 1.6 不 等 。 不 过 ， 我 们 也 在 逐渐 改进 传播 
材料 的 质量 ， 从 而 不 断 降低 折射 率 。 为 简单 起 见 ， 我 们 大 都 假定 光 通 过 光纤 的 速度 
约 为 每 秒 200 000 000 米 ， 对 应 的 折射 率 约 为 1.5。 值 得 一 提 的 是 ， 我 们 已 经 能 够 把 
折射 率 降 低 到 最 大 速度 的 一 个 很 小 的 常数 因子 的 范围 内 了 ! 仅 此 就 堪 称 一 项 了 不 起 
的 成 就 。 





当然 ， 我 们 还 是 不 太 习 惯 以 光速 为 参照 来 思考 ， 因 此 表 1-1 给 出 了 几 个 例子 ， 以 便 
我 们 能 够 直观 地 想象 。 


表 1-1: 真空 与 光纤 中 的 信号 延迟 








路 线 距离 ( km ) ”时 间 : 光 在 真空 中 时间 : 光 在 光纤 中 ”光纤 中 的 往返 时 间 ( RTT ) 
纽约 到 旧金山 4148 14 ms 21 ms 42 ms 

纽约 到 伦敦 5 585 19 ms 28 ms 56 ms 

纽约 到 悉尼 15 993 53 ms 80 ms 160 ms 

赤道 周 长 40 075 133.7 ms 200 ms 400 ms 


光速 已 经 很 快 了 ， 尽 管 如 此 从 纽约 到 悉尼 的 一 个 往返 (RIT) 也 要 花 160 ms。 事 实 
上 ， 以 上 这 些 数 字 都 是 理想 情况 下 的 结果 ， 因 为 我 们 假设 传送 分 组 的 光缆 恰好 是 连 
接 两 个 城市 的 一 条 完美 的 大 弧 形 线路 (地 球 表面 两 点 间 最 短 的 距离 ) 。 而 实际 上 纽约 
和 悉尼 之 间 是 没有 这 样 一 条 线路 的 ， 分 组 旅行 的 距离 比 这 要 长 得 多 。 这 条 线路 中 的 
每 一 跳 都 会 涉及 寻 路 、 处 理 、 排 了 从 和 传输 延迟 。 结 果 呢 ， 纽 约 到 悉尼 的 实际 RTT， 
大 约 在 200~300 ms 之 间 。 即 便 如 此 ， 还 是 很 快 的 ， 对 吧 ? 


我 们 都 不 习惯 用 ms 来 度量 身边 的 事物 ， 但 研究 表明 : 在 软件 交互 中 ， 哪 怕 100~ 
200 ms 左右 的 延迟 ， 我 们 中 的 大 多 数 人 就 会 感觉 到 “拖拉 ”;， 如 果 超 过 了 300 ms 的 
门槛 ， 那 就 会 说 “反应 迟钝 ”， 而 要 是 延迟 达到 1000 ms (1s) 这 个 界限 ， 很 多 用 户 
就 会 在 等 待 响应 的 时 候 分 神 ， 有 人 会 想入非非 ， 有 人 恨不得 忙 点 别 的 什么 事 儿 。 


结论 很 简单 : 要 想 给 用 户 最 佳 的 体验 ， 而 且 保证 他 们 全 神 贯 注 于 手边 的 任务 ， 我 们 
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的 应 用 必须 在 几 百 ms 之 内 响应 。 这 几乎 没有 给 我 们 一 一 特别 是 网 络 ， 留 出 多 少 出 
错 的 余地 。 若 要 成 功 ， 必 须 认真 对 待 网 络 延迟 ， 在 每 个 开发 阶段 都 为 它 设立 明确 的 
标准 。 








CDN (Content Delivery Network， 内 容 分 发 网 络 ) 服务 的 用 途 很 多 ， 但 最 
心 。 重 要 的 就 是 通过 把 内 容 部 署 在 全 球 各 地 ， 让 用 户 从 最 近 的 服务 器 加 载 内 容 ， 
全 大幅 降 低 传播 分 组 的 时 间 。 
或 许 我 们 不 能 让 数据 传输 得 更 快 ， 但 我 们 可 以 缩短 服务 器 与 用 户 之 间 的 距 
离 ! 把 数据 托管 到 CDN 能 够 显著 提高 性 能 。 








1.4 ”延迟 的 最 后 一 公里 

你 说 怪 不 怪 ， 延 迟 中 相当 大 的 一 部 分 往往 花 在 了 最 后 几 公 里 ， 而 不 是 在 横 跨 大 详 或 
大 陆 时 产生 的 ， 这 就 是 所 谓 的 “最 后 一 公里 ”问题 。 为 了 让 你 家 或 你 的 办 公 室 接 入 
互联 网 ， 本 地 ISP 需要 在 附近 安装 多 个 路 由 收集 信号 ， 然 后 再 将 信号 转发 到 本 地 的 
路 由 节点 。 连 接 类 型 、 路 由 技术 和 部 署 方 法 五 花 八 门 ， 分 组 传输 中 的 这 前 儿 跳 往往 
要 花 数 十 ms 时 间 才 能 到 达 ISP 的 主 路 由 器 ! 根据 美国 联邦 通信 委员 会 (FCC) 发 
布 于 2012 年 年 中 的 《美国 宽带 测量 报告 》(Measuring Broadband America)， 在 通 
信 高 峰 的 几 个 小 时 内 : 


光纤 入 户 服务 的 平均 往返 时 间 为 18 ms， 有 线 电视 线路 上 网 平均 为 26 ms， 
DSL 专线 平均 为 43 ms。 











一 一 FCC; 2012 年 7 月 


这 里 18~43 ms 的 延迟 测量 的 还 只 是 ISP 核心 网 络 中 与 用 户 最 近 的 节点 ， 此 时 分 组 其 
至 都 还 没有 启程 呢 ! FCC 的 报告 上 只 反映 了 美国 的 情况 ， 但 最 后 一 公里 的 延迟 却 是 世 
界 任何 一 个 角落 的 互联 网 提供 商 共同 面临 的 问题 。 如 果 你 好 奇 ， 那 只 要 一 条 简单 的 
traceroute 命令 ， 就 能 知道 上 网 服务 商 的 拓扑 结构 和 速度 。 





$> traceroute google.com 

traceroute to google.com (74.125.224.102), 64 hops max, 52 byte packets 
1 10.1.10.1 (10.1.10.1) 7.120 ms 8.925 ms 1.199 ms © 

2 96.157.100.1 (96.157.100.1) 20.894 ms 32.138 ms 28.928 ms 

3 x.santaclara.xxxx.com (68.85.191.29) 9.953 ms 11.359 ms 9.686 ms 
4 x.oakland.xxx.com (68.86.143.98) 24.013 ms 21.423 ms 19.594 ms 

5 68.86.91.205 (68.86.91.205) 16.578 ms 71.938 ms 36.496 ms 

6 x.sanjose.ca.Xxx.com (68.86.85.78) 17.135 ms 17.978 ms 22.870 ms 
7 Xx.529bryant.xxx.com (68.86.87.142) 25.568 ms 22.865 ms 23.392 ms 
8 66.208.228.226 (66.208.228.226) 40.582 ms 16.058 ms 15.629 ms 

9 72.14.232.136 (72.14.232.136) 20.149 ms 20.210 ms 18.020 ms 

0 64.233.174.109 (64.233.174.109) 63.946 ms 18.995 ms 18.150 ms 

1 x.1le1i00.net (74.125.224.102) 18.467 ms 17.839 ms 17.958 ms (2) 





@ 第 1 跳 : 本 地 无 线路 由 器 
如 第 11 跳 : 谷歌 服务 器 


分 组 从 森 尼 维 耳 市 开始 ， 跳 到 圣 克拉 拉 ， 经 过 奥克兰 ， 返 回 圣 何 寒 ,， 又 被 路 由 到 
“529 Bryant” 数 据 中 心 ， 从 那儿 才 开 始 向 谷歌 服务 器 进发 ， 最 终 在 第 11 跳 到 达 目 
的 地 。 整 个 行程 大 约 18 ms， 所 有 延迟 都 算 上 了 ， 还 不 错 。 但 与 此 同时 ， 我 们 的 分 
组 几乎 穿越 了 大 半 个 美国 本 士 ! 

最 后 一 公里 的 延迟 与 提供 商 、 部 署 方法 、 网 络 拓扑 ， 甚 至 一 天 中 的 哪个 时 段 都 有 很 
大 关系 。 作 为 最 终 用 户 ， 如 果 你 想 提高 自己 上 网 的 速度 ， 那 选择 延迟 最 短 的 ISP 是 
最 关键 的 。 








增 志 





大 多 数 网 站 性 能 的 瓶颈 都 是 延迟 ， 而 不 是 带宽 ! 要 理解 为 什么 ， 需 要 明白 
4 4 、TCP 和 HTTP 协议 的 细节 ， 这 也 是 本 书后 面 几 章 要 讨论 的 。 假 如 你 现在 就 
必 ， 着急 知道 ， 可 以 直接 翻 到 10.3.1 节 “ 更 多 带宽 其 实 不 ( 太 ) 重要 ”。 


























使 用 traceroute 测量 延迟 

traceroute 是 一 个 简单 的 网 络 诊断 工具 ， 可 以 列 出 分 组 经 过 的 路 由 节点 ， 以 及 它 在 
IP 网 络 中 每 一 跳 的 延迟 。 为 找到 每 一 跳 的 节点 ， 它 会 向 目标 发 送 一 系列 分 组 ， 每 
次 发 送 时 的 “ 跳 数 限制 ”部 会 递增 (1、2、3， 等 等 )。 在 达到 跳 数 限制 时 ， 中 间 
的 节点 会 返回 ICMP Time Exceeded 消息 ，traceroute 根据 这 个 消息 可 以 计算 出 每 
一 跳 的 延迟 。 

在 Unix 平台 上 ， 可 以 在 命令 行 运行 traceroute。 而 在 Windows 平台 中 ， 相 应 的 
命令 叫 tracert。 








-HH 一 一 
1.5 网络 核心 的 带宽 
光纤 就 是 一 根 “ 光 导 管 "， 比 人 的 头发 稍微 粗 一 点 ， 专 门 用 来 从 一 端 向 另 一 端 传送 光 
信号 。 金 属 线 则 用 于 传送 电信 号 ， 但 信号 损失 、 电 磁 干 扰 较 大 ， 同 时 维护 成 本 也 较 
高 。 这 两 种 线路 我 们 的 数据 分 组 很 可 能 都 会 经 过 ， 但 一 般 长 距离 的 分 组 传输 都 是 通 
过 光纤 完成 的 。 
通过 波 分 复 用 (WDM，Wavelength-Division Multiplexing) 技术 ， 光 纤 可 以 同时 传 
会 很 多 不 同 波长 (信道 ) 的 光 ， 因 而 具有 明显 的 带宽 优势 。 一 条 光纤 连接 的 总 带宽 ， 
等 于 每 个 信道 的 数据 传输 速率 乘 以 可 复 用 的 信道 数 。 
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到 2010 年 初 ， 研 究 人 员 已 经 可 以 在 每 个 信道 中 耦合 400 多 种 波长 的 光线 ， 最 大 容 
量 可 达 171 Gbit/s， 而 一 条 光纤 的 总 带宽 能 够 达到 70 Tbits ! 如 此 大 的 吞吐 量 如 有 果 
换 成 铀 线 (传输 电信 号 ) 可 能 需要 几 千 条 。 自 然 地 ， 像 两 个 大 陆 间 的 海底 数据 传输 ， 
现在 都 已 经 使 用 光纤 连接 了 。 每 条 光缆 会 封装 几 条 光纤 (常见 的 是 4 条 )， 折 算出 来 
的 带宽 容量 能 达到 每 秒 几 百 太 比 特 。 


1.6 网络 边 缘 的 市 宽 


构成 因特网 核心 数据 路 径 的 骨干 或 光纤 连接 ， 每 秒 能 够 移动 数 百 太 比 特 信息 。 然 
而 ， 网 络 边缘 的 容量 就 小 得 多 了 ， 而 且 很 大 程度 上 取决 于 部 署 技术 ， 比 如 拔 号 连接 、 
DSL、 电 缆 、 各 种 无 线 技术 、 光 纤 到 户 ， 甚 至 与 局 域 网 路 由 器 的 性 能 也 有 关系 。 用 
户 可 用 带宽 取决 于 客户 端 与 目标 服务 器 间 最 低 容量 连接 (参见 图 1-1)。 








Akamai 技术 公司 在 全 球 部 署 了 CDN， 服 务 器 遍及 世界 各 地 ， 而 且 每 季度 都 会 发 
布 一 份 免费 的 带宽 平均 速度 报告 (由 他 们 的 服务 器 测量 )， 地 址 为 : http://www. 
akamai.io。 表 1-2 中 展示 的 是 2012 年 年 中 监测 到 的 世界 各 地 的 平均 带宽 。 


表 1-2: 2012 年 年 中 Akamai 公 司 服务 器 的 平均 带宽 








排名 国家 和 地 区 平均 Mbit/s 年 增长 
全 球 3.1 17% 

1 韩国 14.2 一 10% 

2 日 本 11.7 6.8% 

3 香港 10.9 16% 

4 瑞士 10.1 24% 

5 荷兰 9.9 12% 

9 美国 8.6 27% 





以 上 数据 不 包括 移动 网 络 的 流量 ， 这 一 块 我 们 稍 后 还 要 详细 讨论 。 目 前 ， 可 以 肯定 
移动 网 络 的 速度 差异 很 大 ， 而 且 一 般 都 更 慢 。 即 便 如 此 ，2012 年 上 半年 全 球 宽带 的 
带宽 也 只 有 2.6 Mbit/s ! 韩国 以 15.7 Mbit/s 的 平均 带宽 位 居 第 1， 美 国 的 6.7 Mbit/s 
位 列 第 12 名 。 


为 了 更 好 地 理解 这 些 数字 ， 我 们 举 个 例子 : 视频 网 站 的 高 清 视频 流 ， 根 据 分 辩 率 高 
低 以 及 编 解 码 器 不 同 ， 可 能 需要 2~10 Mbit/s。 因 此 ， 一 般 用 户 在 网 络 末 端 观看 低 分 
状 率 的 流 视频 几乎 就 可 以 消耗 掉 其 所 有 带宽 。 对 于 一 个 可 能 会 有 多 人 同时 上 网 的 家 
庭 而 言 ， 这 个 结果 并 不 理想 。 























搞 清楚 每 个 用 户 的 带宽 瓶颈 通常 不 是 件 容易 的 事 ， 却 又 非常 重要 。 同 样 ， 为 了 满足 
大 家 的 好 奇 心 ， 推 荐 一 个 在 线 服务 吧 : Ookla 运营 的 http://speedtest.net (图 1-2)， 
可 以 测试 客户 端 到 某 个 本 地 服务 器 的 上 传 和 下 载 速 度 。 在 后 面 讨论 TCP 的 时 候 ， 我 
们 会 解释 为 什么 选择 本 地 服务 器 很 重要 。 在 这 些 服务 器 上 运行 测试 可 以 验证 你 的 
ISP 在 广告 中 吹 趴 的 速度 。 








四 PING DOWNLOAD SPEED 中 UPLOAD SPEED 
41 ms 


@ 11.76wr 














1-2: 上 传 和 下 载 速度 测试 (speedtest.net) 


虽然 与 ISP 的 高 带宽 连接 是 必要 的 ， 但 这 个 高 带宽 并 能 不 保证 端 到 端的 传输 速度 。 
由 于 请 求 密集 、 硬 件 故障 、 网 络 攻击 ， 以 及 其 他 很 多 原因 ， 网 络 的 某 个 中 间 节 点 随 
时 都 有 可 能 发 生 拥塞 。 吞 吐 量 和 延迟 波动 大 是 因特网 固有 的 特点 。 要 预见 、 控 制 、 
适应 瞬息 万 变 的 “网 络 天 气 ” 可 不 容易 。 


1.7 目标 : 高 市 宽 和 低 延 迟 


人 们 对 高 带宽 的 需求 增长 迅速 ， 很 大 程度 是 受到 了 在 线 流 视频 的 拉动 ， 目 前 的 视频 
流量 已 经 占 到 全 部 因特网 流量 的 一 半 以 上 。 好 在 ， 虽 然 不 一 定 很 便宜 ， 但 我 们 有 很 
多 方法 可 以 提高 容量 。 比 如 ， 可 以 在 光纤 链 路 中 部 署 更 多 光纤 、 在 拥塞 的 路 由 之 间 
铺设 更 多 线路 ， 其 至 是 改进 WDM 技术 ， 以 便 让 现 有 连接 能 够 传输 更 多 数据 。 


电信 市 场 研究 及 咨询 公司 TeleGeography 估计 ， 我 们 到 2011 年 (平均) 只 使 用 了 海 
底 光 缆 可 用 容量 的 20% 左右 。 更 重要 的 是 ，2007 年 到 2011 年 ， 太 平 洋 海底 光缆 全 
部 新 增 容量 中 有 一 半 以 上 是 因为 WDM 升级 带 来 的 : 光缆 还 是 那些 光缆 ， 但 两 端 多 
路 传输 数据 的 技术 进步 了 。 当 然 ， 技 术 进 步 也 不 是 没有 止境 ， 任 何 介 质 超 过 一 定 限 
度 都 会 出 现 性 能 递减 效应 。 不 管 怎 样 ， 只 要 企业 的 经 济 条 件 允 许 ， 就 没有 理由 认为 
带宽 会 停止 增长 的 脚步 。 就 算 技术 停 疝 不 前 ， 还 是 可 以 铺设 更 多 的 光缆 。 
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另 一 方面 ， 减 少 延 迟 时 间 则 要 困难 得 多 。 通 过 提升 光纤 线路 的 质量 ， 可 以 让 光 信 号 
传输 的 速度 更 接近 光速 ， 比 如 采用 折射 率 更 低 的 材料 、 速 度 更 快 的 路 由 器 和 中 继 器 。 
然而 ， 当 前 光纤 折射 率 已 经 达到 了 1.5 左右 ， 最 大 的 提升 幅度 预计 在 30% 左右 。 


反 过 来 想 ， 不 能 让 光线 跑 得 更 快 ， 但 可 以 把 距离 缩短 。 地 球 上 两 点 之 间 的 最 短 距离 ， 
取决 于 这 两 点 之 间 的 大 圆 踊 。 事 实 上 ， 我 们 在 设计 和 铺设 电缆 时 ， 都 是 尽量 缩短 距 
离 的 。 当 然 ， 考 虑 到 地 形 特点 、 社 会 政治 原因 ， 以 及 相关 成 本 ， 有 些 线路 也 不 是 最 
短 的 。 总 之 ， 光 速 为 减少 延迟 设 定 了 上 限 ， 而 从 很 多 方面 来 看 ， 我 们 的 基础 设施 似 
乎 也 已 经 达到 了 这 个 极限 。 

遗憾 的 是 ， 人 类 不 太 可 能 跳出 物理 定律 的 “和 掌心”"”。 如 果 需 要 针对 延迟 采取 优化 措 
施 ， 就 必须 从 设计 和 优化 协议 及 应 用 着 手 ， 并 且 时 刻 牢记 光速 的 限制 。 可 以 减少 往 
返 、 把 数据 部 署 到 接近 客户 端的 地 方 ， 以 及 在 开发 应 用 时 通过 各 种 技术 隐藏 延迟 。 
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TCP 的 构成 








因特网 有 两 个 核心 协议 : IP 和 TCP。IP， 即 Internet Protocol (因特网 协议 )， 负 
责 联 网 主机 之 间 的 路 由 选择 和 寻 址 ; TCP， 即 Transmission Control Protocol (传输 
控制 协议 )， 负 责 在 不 可 靠 的 传输 信道 之 上 提供 可 靠 的 抽象 层 。TCP/IP 也 常 被 称 为 
“因特网 协议 套件 ”(Internet Protocol Suite)， 是 由 Vint Cerf 和 Bob Khan 在 他 们 
1974 的 论文 “A Protocol for Packet Network Intercommunication” (一 种 分 组 网 络 互 
通 的 协议 ) 中 首次 提出 来 的 。 


最 早 的 建议 (RFC 675) 经 过 几 次 修订 ， 于 1981 年 作为 TCP/IP 标准 第 4 版 发 布 。 
发 布 时 并 不 是 一 个 标准 ， 而 是 两 个 独立 的 RFC: 





。 RFC 791 
。 RFC 793 





Internet Protoco!l; 





‘Transmission Control Protocol。 


从 那 时 起 ，TCP 经 过 了 多 次 改进 和 完善 ， 但 核心 内 容 变 化 不 大 。TCP 很 快 取代 了 之 
前 的 协议 ， 成 为 World Wide Web、 文 件 传 输 、P2P 等 众多 流行 应 用 的 选择 。 


TCP 负责 在 不 可 靠 的 传输 信道 之 上 提供 可 靠 的 抽象 层 ， 向 应 用 层 隐藏 了 大 多 数 网 络 
通信 的 复杂 细节 ， 比 如 丢 包 重 发 、 按 序 发 送 、 拥 塞 控制 及 避免 、 数 据 完整 ， 等 等 。 
采用 TCP 数据 流 可 以 确保 发 送 的 所 有 字 节 能 够 完整 地 被 接收 到 ， 而 且 到 达 客 户 端的 
顺序 也 一 样 。 也 就 是 说 ，TCP 专门 为 精确 传送 做 了 优化 ， 但 并 未 过 多 顾及 时 间 。 正 
如 稍 后 我 们 会 谈 到 的 ， 这 一 点 也 给 优化 浏览 器 Web 性 能 带 来 了 挑战 。 


HTTP 标准 并 未 规定 TCP 就 是 唯一 的 传输 协议 。 如 果 你 愿意 ， 还 可 以 通过 UDP (用 
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户 数据 报 协 议 ) 或 者 其 他 可 用 协议 来 发 送 HTTP 消息 。 但 在 现实 当中 ， 由 于 TCP 提 
供 了 很 多 有 用 的 功能 ， 几 乎 所 有 HTTP 流量 都 是 通过 TCP 传送 的 。 

因此 ， 理 解 TCP 的 某 些 核心 机 制 就 成 为 了 优化 Web 体验 的 必修 课 。 虽 然 我 们 一 般 
不 会 直接 使 用 TCP 套 接口 ， 但 应 用 层 的 一 些 决定 可 能 会 对 TCP 以 及 底层 网 络 的 性 
能 产生 极 大 影响 。 








TCP 和 IP 协议 的 历史 

我 们 都 知道 有 IPv4 和 JIPv6, 那 IPvl-~3 和 JIPv5 呢 ? IPv4 中 的 4 表示 TCP/IP 协议 的 第 4 
个 版 本 ， 发 布 于 1981 年 9 月 。 最 初 的 TCP/IP 建议 中 同时 包含 两 个 协议 ， 但 标准 草案 
第 4 版 将 这 两 个 协议 分 开 ， 使 之 各 自 成 为 独立 的 RFC。 实 际 上 ,IPv4 中 的 V4 只 是 表 
明了 它 与 TCP 前 3 个 版 本 的 承继 关系 ,之 前 并 没有 单独 的 IPv1、JIPv2 或 IPV3 协议 。 
1994 年 ， 当 工作 组 着 手 制 定 Internet Protocol next generation (IPng) 需要 一 个 新 版 
本 号 时 ，v5 已 经 被 分 配给 了 另 一 个 试验 性 协议 Internet Stream Protocol (ST)。 但 
ST 一直 没有 什么 进展 ， 这 也 是 我 们 为 什么 很 少 听 说 它 的 原因 。 结 有 果 TCP/IP 的 下 
一 版 本 就 成 了 IPv6。 


2.1 三 次 握手 

所 有 TCP 连接 一 开始 都 要 经 过 三 次 握手 ( 见 图 2-1)。 客 户 端 与 服务 器 在 交换 应 用 数 
据 之 前 ， 必 须 就 起 始 分 组 序列 号 ， 以 及 其 他 一 些 连接 相关 的 细节 达成 一 致 。 出 于 安 
全 考虑 ， 序 列 号 由 两 端 随机 生成 。 

















发 送 端 接收 端 

















。 SYN 
客户 端 选 择 一 个 随机 序列 号 x， 并 发 送 一 个 SYN 分组， 其 中 可 能 还 包括 其 他 TCP 
标志 和 选项 。 


。 SYNACK 
服务 器 给 x 加 1， 并 选择 自己 的 一 个 随机 序列 号 y， 追 加 自己 的 标志 和 选项 ， 然 
后 返回 啊 应 。 


。 ACK 
客户 端 给 x 和 y 加 1 并 发 送 握手 期 间 的 最 后 一 个 ACK 分 组 。 


三 次 握手 完成 后 ， 客 户 端 与 服务 器 之 间 就 可 以 通信 了 。 客 户 端 可 以 在 发 送 ACK 分 
组 之 后 立即 发 送 数 据 ， 而 服务 器 必须 等 接收 到 ACK 分 组 之 后 才能 发 送 数 据 。 这 个 
启动 通信 的 过 程 适用 于 所 有 TCP 连接 ， 因 此 对 所 有 使 用 TCP 的 应 用 具有 非常 大 的 
性 能 影响 ， 因 为 每 次 传输 应 用 数据 之 前 ， 都 必须 经 历 一 次 完整 的 往返 。 











举 个 例子 ， 如 果 客 户 端 在 纽约 ， 服 务 器 在 伦敦 ， 要 通过 光纤 启动 一 次 新 的 TCP 连 
接 ， 光 三 次 握手 至 少 就 要 花 56 ms (参见 表 1-1) : 向 伦敦 发 送 分 组 需要 28 ms， 响 
应 发 回 纽约 又 要 28 ms。 在 此 ， 连 接 的 带宽 对 时 间 没 有 影响 ， 延 迟 完 全 取决 于 客户 
端 和 服务 器 之 间 的 往返 时 间 ， 这 其 中 主要 是 纽约 到 伦敦 之 间 的 传输 时 间 。 





三 次 握手 带 来 的 延迟 使 得 每 创建 一 个 新 TCP 连接 都 要 付出 很 大 代价 。 而 这 也 决定 了 
提高 TCP 应 用 性 能 的 关键 ， 在 于 想 办 法 重用 连接 。 








TCP 快速 打开 


遗憾 的 是 ， 连 接 并 不 是 想 重 用 就 可 以 重用 的 。 事 实 上 ， 由 于 非常 短 的 TCP 连接 在 
互联 网 上 随处 可 见 ， 握 手 阶 段 已 经 成 为 影响 网 络 总 延迟 的 一 个 重要 因素 。 为 解决 
这 个 问题 ， 人 们 正在 积极 寻找 各 种 方案 ， 其 中 TFO (TCP Fast Open，TCP 快速 打 
开 ) 就 是 这 样 一 种 机 制 ， 它 致力 于 减少 新 建 TCP 连接 带 来 的 性 能 损失 。 


经 过 流量 分 析 和 网 络 模 拟 ， 谷 歌 研 究 人 员 发 现 TFO 平均 可 以 降低 HTTP 事务 网 络 
延迟 15% 、 整 个 页 面 加 载 时 间 10% 以 上 。 在 某 些 延迟 很 长 的 情况 下 ， 降 低 幅 度 其 
至 可 达 409%。 


Linux 3.7 及 之 后 的 内 核 已 经 在 客户 端 和 服务 器 中 支持 TFO， 因 此 成 为 了 客户 痛 和 
服务 器 操作 系统 选 型 的 有 力 候选 方案 。 即 便 如 此 ，TEO 并 不 能 解决 所 有 问题 。 它 
虽然 有 助 于 减少 三 次 握手 的 往返 时 间 ， 但 却 只 能 在 某 些 情况 下 有 效 。 上 比如， 随同 
SYN 分 组 一 起 发 送 的 数据 净 荷 有 最 大 尺寸 限制 、 只 能 发 送 某 些 类 型 的 HTTP 请 
求 ， 以 及 由 于 依赖 加 密 cookie， 只 能 应 用 于 重复 的 连接 。 要 了 解 有 关 TFO 容量 及 
局 限 性 的 更 多 细节 ， 请 参考 IETF 最 新 的 “TCP Fast Open” 草 案 。 
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2.2 拥塞 预防 及 控制 


1984 年 初 ，John Nagle 提 到 了 一 个 被 称 为 “拥塞 参 溃 ”的 现象 ， 这 个 现象 会 影响 市 
点 间 带 宽容 量 不 对 称 的 任何 网 络 : 





拥塞 控制 是 复杂 网 络 中 众所周知 的 一 个 问题 。 我 们 发 现 国 防 部 的 Internet 
Protocol (IP) 一 一 纯粹 的 数据 报 协 议 ， 和 Transmission Control Protocol 
(TCP) 一 一 传输 层 协 议 , 在 一 块 使 用 时 , 由 于 传输 层 与 数据 报 层 之 间 的 交互 ， 
会 导致 一 些 不 常见 的 拥塞 问题 。 特 别 是 卫 网 关 容 易 受 到 我 们 称 为 “拥塞 崩 沉 ” 
现象 的 严重 影响 ， 尤 其 是 在 这 种 网 关连 接 不 同 带宽 的 网 络 时 …… 


可 能 是 往返 时 间 超 过 了 所 有 主机 的 最 大 中 断 间 隔 ， 于 是 相应 的 主机 会 在 网 络 
中 制造 越 来 越 多 的 数据 报 副本 ， 使 得 整个 网 络 陷入 竣 普 。 最 终 ， 所 有 交换 节 
点 的 缓冲 区 部 将 被 填 满 ， 多 出 来 的 分 组 必须 删 掉 。 目 前 的 分 组 往返 时 间 已 经 
设 定 为 最 大 值 。 主 机 会 把 每 个 分 组 都 发 送 好 几 次 ， 结 果 每 个 分 组 的 某 个 副本 
会 抵达 目标 。 这 就 是 拥塞 前 渍 。 

这 种 情况 永远 存在 。 达 到 饱和 状态 时 ， 只 要 选择 被 删除 分 组 的 算法 起 当 ， 网 
络 就 可 以 退 而 求 其 次 地 持续 运行 下 去 。 
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这 份 报 告 的 结论 是 拥塞 月 溃 不 会 对 ARPANET 造成 影响 ， 因 为 其 大 多 数 节 点 的 带 
宽 相 同 ， 而 且 甚 骨干 网 的 容量 相对 大 得 多 。 然 而 ， 这 两 种 情况 没有 持续 太 和 久 。1986 
年 ， 随 着 加 入 网 络 的 市 点 数量 (5000+) 及 类 型 日 益 增多 ， 该 网 络 中 发 生 了 一 系列 
拥塞 崩 潢 故障。 个别 情况 下 ， 容 量 下 降 为 千 分 之 一 ， 网 络 完 全 瘫痪 。 














为 了 解决 这 些 问题 ，TCP 加 入 了 很 多 机 制 ， 以 便 控 制 双向 发 送 数 据 的 速度 ， 比 如 流 
量 控 制 、 拥 塞 控 制 和 拥塞 预防 机 制 。 
‘es ARPANET (Advanced Research Projects Agency Network， 高 级 研究 计划 局 
AS | 网 络 ) 是 现代 互联 网 的 前 身 ， 是 世界 上 第 一 个 实际 运行 的 分 组 交换 网 络 。 这 
性， 个 项 目 于 1959 年 正式 启动 ，1983 年 TCP/IP 作为 主要 通信 协议 取代 了 原来 
的 NCP (Network Control Program) 协议 。 后 来 呢 ， 那 大 家 就 都 知道 了 。 





2.2.1 流量 控制 

流量 控制 是 一 种 预防 发 送 端 过 多 向 接收 端 发 送 数 据 的 机 制 。 否 则 ， 接 收 问 可 能 因为 
忙碌 、 负 载重 或 缓冲 区 既定 而 无 法 处 理 。 为 实现 流量 控制 ，TCP 连接 的 每 一 方 都 要 
通告 (图 2-2) 自己 的 接收 窗口 (rwnd)， 其 中 包含 能 够 保存 数据 的 缓冲 区 空间 大 小 




















图 2-2: 通告 接收 窗口 (rwnd) 大 小 





第 一 次 建立 连接 时 ， 两 端 都 会 使 用 自身 系统 的 默认 设置 来 发 送 rwnd。 浏 览 网 页 通常 主要 是 
从 服务 器 向 客户 端 下 载 数据 ， 因 此 客户 端 窗口 更 可 能 成 为 瓶颈 。 然 而 ， 如 果 是 在 上 传 图 片 
或 视频 ， 即 客户 端 向 服务 器 传送 大 量 数据 时 ， 服 务 器 的 接收 窗口 又 可 能 成 为 制约 因素 。 


不 管 怎样 ， 如 果 其 中 一 端 跟 不 上 数据 传输 ， 那 它 可 以 向 发 送 端 通告 一 个 较 小 的 窗口 。 
假如 窗口 为 零 ， 则 意味 着 必须 由 应 用 层 先 清空 缓冲 区 ， 才 能 再 接收 剩余 数据 。 这 个 过 
程 贯 穿 于 每 个 TCP 连接 的 整个 生命 周期 每 个 ACK 分 组 都 会 携带 相应 的 最 新 rwnd 
值 ， 以 便 两 端 动态 调整 数据 流速 ， 使 之 适应 发 送 端 和 接收 端的 容量 及 处 理 能 力 。 




















窗口 缩放 (RFC 1323) 
最 初 的 TCP 规范 分 配给 通告 窗口 大 小 的 字段 是 16 位 的 ， 这 相当 于 设 定 了 发 送 闹 和 
接收 茹 窗口 的 最 大 值 (216 即 65 535 字 节 )。 结 果 ， 在 这 个 限制 内 经 常 无 法 获得 最 优 
性 能 ， 特 别 是 在 那些 “带宽 延迟 积 ”( 参 见 2.3 节 “ 带 宽 延 迟 积 ") 很 高 的 网 络 中 。 
为 解决 这 个 问题 ，REFC 1323 提供 了 “TCP 窗口 缩放 ”(TCP Window Scaling) 选项 ， 
可 以 把 接收 窗口 大 小 由 65 535 字 节 提高 到 1G 字 节 | 缩放 TCP 窗口 是 在 三 次 握手 期 
间 完 成 的 ， 其 中 有 一 个 值 表 示 在 将 来 的 ACK 中 左 移 16 位 窗口 字段 的 位 数 。 
今天 ，TCP 窗口 缩放 机 制 在 所 有 主要 平台 上 都 是 默认 局 用 的 。 不 过 ， 中 间 节 点 和 
路 由 器 可 以 重 写 ， 甚 至 完全 去 掉 这 个 选项 。 如 果 你 的 服务 器 或 客户 闹 的 连接 不 能 
完全 利用 现 有 带宽 ， 那 往往 该 先 查 一 查 窗 口 大 小 。 在 Linux 中 ， 可 以 通过 如 下 命 
令 检 查 和 局 用 窗口 缩放 选项 : 
。 $> sysctl net.ipv4.tcp window scaling 


。 $> sysctl -w net.ipv4.tcp window_ scaling=1 
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2.2.2 ” 慢 启 动 


尽管 TCP 有 了 流量 控制 机 制 ， 但 网 络 拥塞 崩溃 仍然 在 1980 年 代 中 后 期 浮 出 水 面 。 
流量 控制 确实 可 以 防止 发 送 端 向 接收 端 过 多 发 送 数据 ， 但 却 没 有 机 制 预防 任何 一 端 
向 流 在 网 络 过 多 发 送 数 据 。 换 句 话说 ， 发 送 端 和 接收 端 在 连接 建立 之 初 ， 谁 也 不 知 
道 可 用 带宽 是 多 少 ， 因 此 需要 一 个 估算 机 制 ， 然 后 还 要 根据 网 络 中 不 断 变化 的 条 件 
而 动态 改变 速度 。 


要 说 明 这 种 动态 适应 机 制 的 好 处 ， 可 以 想象 你 在 家 里 观看 一 个 大 型 的 流 视频 。 视 频 
服务 器 会 尽 最 大 努力 根据 你 的 下 行 连接 提供 最 高 品质 信息 。 而 此 时 ， 你 家 里 又 有 人 
打开 一 个 新 连接 下 载 某 个 软件 的 升级 包 。 可 供 视 频 流 使 用 的 下 行 带宽 一 下 子 少 了 很 
多 ， 视 频 服务 器 必须 调整 它 的 发 送 速 度 。 否 则 ， 如 果 继 续 保 持 同 样 的 速度 ， 那 么 数 
据 很 快 就 会 在 某 个 中 间 的 网 关 越 积 越 多 ， 最 终 会 导致 分 组 被 删除 ， 从 而 降低 网 络 传 


给 效率 。 

















1988 年 ，Van Jacobson 和 Michael J. Karels 撰文 描述 了 解决 这 个 问题 的 几 种 算法 : 
慢 启 动 、 拥 塞 预防 、 快 速 重 发 和 快速 恢复 。 这 4 种 算法 很 快 被 写 进 了 TCP 规范 。 事 
实 上 ， 正 是 由 于 这 几 种 算法 加 入 TCP， 才 让 因特网 在 20 世纪 80 年代 末 到 90 年 代 
初 流 量 暴 增 时 免 于 大 崩溃。 


要 理解 慢 启 动 ， 最 好 看 一 个 例子 。 同 样 ， 假 设 纽约 有 一 个 客户 端 ， 尝 试 从 位 于 伦敦 
的 服务 器 上 取得 一 个 文件 。 首 先 ， 三 次 握手 ， 而 且 在 此 期 间 双 方 各 自 通过 ACK 分 
组 通告 自己 的 接收 窗口 (rwnd) 大 小 (图 2-2)。 在 发 送 完 最 后 一 次 ACK 分 组 后 ， 
就 可 以 交换 应 用 数据 了 。 

此 时 ， 根 据 交换 数据 来 估算 客户 端 与 服务 器 之 间 的 可 用 带宽 是 唯一 的 方法 ， 而 且 这 
也 是 慢 局 动 算法 的 设计 思路 。 首 先 ， 服 务 器 通过 TCP 连接 初始 化 一 个 新 的 拥塞 窗口 
(cwnd) 变量 ， 将 其 值 设置 为 一 个 系统 设 定 的 保守 值 〈 在 Linux 中 就 是 initcwnd) 。 




















。 拥塞 窗口 大 小 (cwnd) 
发 送 端 对 从 客户 端 接收 确认 (ACK) 之 前 可 以 发 送 数据 量 的 限制 。 


发 送 端 不 会 通告 cwnd 变量 ， 即 发 送 端 和 接收 端 不 会 交换 这 个 值 。 此 时 ， 位 于 伦敦 
的 服务 器 只 是 维护 这 么 一 个 私有 变量 。 此 时 又 有 一 条 新 规则 ， 即 客户 端 与 服务 器 之 
间 最 大 可 以 传输 (未 经 ACK 确认 的 ) 数据 量 取 rwnd 和 cwnd 变量 中 的 最 小 值 。 那 
服务 器 和 客户 端 怎么 确定 拥塞 窗口 大 小 的 最 优 值 呢 ”毕竟 ， 网 络 状 况 随时 都 在 变化 ， 
即使 相同 的 两 个 网 络 节 点 之 间 也 一 样 (前 面 的 例子 已 经 展示 了 这 一 点 )。 如 果 能 通过 
算法 来 确定 每 个 连接 的 窗口 大 小 ， 而 不 用 手工 调整 就 最 好 了 。 
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解决 方案 就 是 慢 启动 ， 即 在 分 组 被 确认 后 增 大 窗口 大 小 ， 慢 慢 地 启动 ! 最 初 ，cwnd 
的 值 只 有 1 个 TCP 段 。1999 年 4 月 ，RFC 2581 将 其 增加 到 了 4 个 TCP 段 。2013 
年 4 月 ，RFC 6928 再 次 将 其 提高 到 10 个 TCP 段 。 





新 TCP 连接 传输 的 最 大 数据 量 取 rwnd 和 cwnd 中 的 最 小 值 ， 而 服务 器 实际 上 可 以 
向 客户 端 发 送 4 个 TCP 段 ， 然 后 就 必须 停 下 来 等 待 确认 。 此 后 ， 每 收 到 一 个 ACK， 
慢 启动 算法 就 会 告诉 服务 器 可 以 将 它 的 cwnd 窗口 增加 1 个 TCP 段 。 每 次 收 到 ACK 
后 ， 都 可 以 多 发 送 两 个 新 的 分 组 。TCP 连接 的 这 个 阶段 通常 被 称 为 “指数 增长 ” 阶 
段 (图 2-3) ， 因 为 客户 端 和 服务 器 都 在 向 两 者 之 间 网 络 路 径 的 有 效 带 宽 迅 速 靠拢 。 











分 组 丢失 〈 丢 包 ) 


拥塞 控制 











(次 dDI) 今 汗 卫 惑 潜 薄 

















图 2-3: 拥塞 控制 和 拥塞 预防 

为 什么 知道 有 个 慢 启 动 对 我 们 构建 浏览 器 应 用 这 么 重要 呢 ? 因 为 包括 HTTP 在 内 的 
很 多 应 用 层 协议 都 运行 在 TCP 之 上 ， 无 论 带 宽 多 大 ， 每 个 TCP 连接 都 必须 经 过 慢 
启动 阶段 。 换 句 话说 ， 我 们 不 可 能 一 上 来 就 完全 利用 连接 的 最 大 带宽 | 

相反 ， 我 们 要 从 一 个 相对 较 小 的 拥塞 窗口 开始 ， 每 次 往返 都 令 其 翻 倍 (指数 式 增 
长 )。 而 达到 某 个 目标 吞吐 量 所 需 的 时 间 ， 就 是 客户 端 与 服务 器 之 间 的 往返 时 间 和 初 
始 拥 塞 窗口 大 小 的 函数 (公式 2-1)。 


公式 2-1: cwnd 大 小 达到 N 所 需 的 时 间 











时 间 = 往返 时 间 x fiog 而 三 -cna 有 
下 面 我 们 就 来 看 一 个 例子 ， 假 设 : 


。 客户 端 和 服务 器 的 接收 窗口 为 65 535 字 节 (64 KB ) ; 
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。 初始 的 拥塞 窗口 : 4 段 (RFC 2581) ; 
。 往返 时 间 是 56 ms (伦敦 到 纽约 )。 


培 必 ， 
和 这 里 及 后 面 例子 中 的 初始 拥塞 窗口 都 会 使 用 原来 (RFC 2581 规定 ) 的 4 
心 。 段 ， 因 为 这 仍然 是 目前 大 多 数 服 务 器 中 常见 的 值 。 当 然 ， 你 肯定 不 会 犯 这 








:种 错误 的 ， 对 吧 ? 接 下 来 的 例子 能 很 好 地 说 明 为 什么 你 该 更 新 内 核 了 。 


先 不 管 64 KB 的 接收 窗口 ， 新 TCP 连接 的 吞吐 量 一 开始 是 受 拥 塞 窗 口 初 始 值 限制 
的 。 计 算 可 知 ， 要 达到 64 KB 的 限制 ， 需 要 把 拥塞 窗口 大 小 增加 到 45 段 ， 而 这 需 
要 224 ms: 


65 535 字 节 


A TL 
1460 字 刷 “和 5 有 段 





45 
56 ms x [eal = 224 ms 


要 达到 客户 端 与 服务 器 之 间 64 KB 的 吞吐 量 ， 需 要 4 次 往返 〈 图 2-4) ， 几 百 ms 的 
延迟 | 至 于 客户 端 与 服务 器 之 间 实 际 的 连接 速率 是 不 是 在 Mbit/s 级 别 ， 丝 毫 不 影响 
这 个 结果 。 这 就 是 慢 启 动 。 





( 漆 ) 今 汗 开 惑 典当 
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图 2-4: 拥塞 窗口 大 小 增长 示意 图 


为 减少 增长 到 拥塞 窗口 的 时 间 ， 可 以 减少 客户 端 与 服务 器 之 间 的 往返 时 间 。 比 如 ， 
把 服务 器 部 署 到 地 理 上 靠近 客户 端的 地 方 。 要 么 ， 就 把 初始 拥塞 窗口 大 小 增加 到 
RFC 9828 规定 的 10 段 。 








慢 启 动 导致 客户 端 与 服务 器 之 间 经 过 儿 百 ms 才能 达到 接近 最 大 速度 的 问题 ， 对 于 
大 型 流 式 下 载 服务 的 影响 倒 不 显著 ， 因 为 慢 局 动 的 时 间 可 以 分 摊 到 整个 传输 周期 内 
消化 掉 。 


可 是 ， 对 于 很 多 HTTP 连接 ， a 突 发 的 连接 而 言 ， 常 常会 出 现 还 没 
有 达到 最 大 窗口 请 求 就 被 终止 的 情 ? 。 换 句 话说 ， 很 多 Web 应 用 的 性 人 
务 器 与 客户 端 之 间 往 返 因为 慢 启 动 限制 了 可 用 的 春 吐 量 ， 而 这 对 于 小 
文件 传输 非常 不 利 。 

















慢 启动 重启 
了 调节 新 连接 的 传输 速度 ，TCP 还 实现 了 SSR (Slow-Start Restart， 慢 启动 重 
启 ) 机 制 。 这 种 机 制 会 在 连接 空闲 一 定时 间 后 重 置 连接 的 拥塞 窗口 。 道 理 很 简单 ， 
在 连接 空闲 的 同时 ， 网 络 状况 也 可 能 发 生 了 变化 ， 为 了 避免 拥塞 ， 理 应 将 拥塞 窗 
口 重 置 回 “安全 的 ”默认 值 。 


毫 无 疑问 ，SSR 对 于 那些 会 出 现 突 发 空闲 的 长 周期 TCP 连接 (比如 HTTP 的 
keep-alive 连接 ) 有 很 大 的 影响 。 因 此 ， 我 们 建议 在 服务 器 上 禁用 SSR。 在 Linux 
平台 ， 可 以 通过 如 下 命令 来 检查 和 茶 用 SSR: 


。 $> sysctl net.ipv4.tcp_ slow start after idle 








。 $> sysctl -w net.ipv4.tcp_slow_ start after_idle=0 





为 演示 三 次 握手 和 慢 启 动 对 简单 HTTP 传输 的 影响 ， 我 们 假设 纽约 的 客户 端 需要 通 
过 TCP 连接 向 伦敦 的 服务 器 请 求 一 个 20 KB 的 文件 (图 2-5) ， 下 面 列 出 了 连接 的 
参数 。 


。 往返 时 间 : 56 ms。 

。 客户 端 到 服务 器 的 带宽 : 5 Mbit/s。 

。 客户 端 和 服务 器 接收 窗口 : 65 535 字 

。 初始 的 拥塞 窗口 : 4 段 (4x1460 ee ~ 5.7KB ) 。 

。 服务 器 生成 响应 的 处 理 时 间 : 40 ms。 

。 设 有 分 组 丢失 、 每 个 分 组 都 要 确认 、GET 请 求 只 占 1 段 。 
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图 2-5: 通过 新 TCP 连接 取得 文件 


。 0 ms: 客户 端 发 送 SYN 分 组 开始 TCP 握手 。 

。 28 ms: 服务 器 响应 SYN-ACK 并 指定 其 rwnd 大 小 。 

。 56 ms: 客户 端 确认 SYN-ACK， 指定 其 rwnd 大 小 ， 并 立即 发 送 HTTP GET 请 求 。 

。 84 ms: 服务 器 收 到 HTTP 请 求 。 

。 124 ms: 服务 器 生成 20 KB 的 响应 ， 并 发 送 4 个 TCP 段 (初始 cwnd 大 小 为 4)， 
然后 等 待 ACK。 


。 152 ms: 
。 180 ms: 
。 208 ms: 
。 236 ms: 
。 264 ms: 


客户 端 收 到 4 个 段 ， 并 分 别 发 送 ACK 确认 。 
服务 器 针对 每 个 ACK 递增 cwnd， 然 后 发 送 8 个 TCP 段 。 
客户 端 接 收 8 个 段 ， 并 分 别 发 送 ACK 确认 。 
服务 器 针对 每 个 ACK 递增 cwnd， 然 后 发 送 剩 余 的 TCP 段 。 
客户 端 收 到 剩余 的 TCP 段 ， 并 分 别 发 送 ACK 确认 。 





| 大 
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大 家 可 以 练习 一 下 ， 如 果 将 cwnd 值 设置 为 10 个 TCP 段 ， 那 么 图 2-5 所 示 
4 








4S 4 ， 的 过 程 将 减少 一 次 往返 ， 性 能 可 以 提升 22% ! 


坊 
1 








通过 新 TCP 连接 在 往返 时 间 为 56 ms 的 客户 端 与 服务 器 间 传 输 一 个 20 KB 的 文件 需 
要 264 ms ! 作为 对 比 ， 现 在 假设 客户 端 可 以 重用 同一 个 TCP 连接 (图 2-6)， 再 发 
送 一 次 相同 的 请 求 。 








发 送 端 接收 端 





i 














2-6: 通过 已 有 的 TCP 连接 取得 文件 


。 0 ms: 客户 端 发 送 HTTP 请 求 。 

。 28 ms: 服务 器 收 到 HTTP 请 求 。 

。 68 ms: 服务 器 生成 20 KB 响应 ， 但 cwnd 已 经 大 于 发 送 文件 所 需 的 15 段 了 ， 
此 一 次 性 发 送 所 有 数据 段 。 

。 96 ms: 客户 端 收 到 所 有 15 个 段 ， 分 别 发 送 ACK 确认 。 


同一 个 连接 、 同 样 的 请 求 ， 但 没有 三 次 握手 和 慢 启 动 ， 只 花 了 96 ms， 人 性 能 提升 幅 
度 达 275% | 





以 上 两 种 情况 下 ， 服 务 器 和 客户 端 之 间 的 5 Mbits 带宽 并 不 影响 TCP 连接 的 启动 阶 
段 。 此 时 ， 延 迟 和 拥塞 窗口 大 小 才 是 限制 因素 。 

事实 上 ， 如 果 增 大 往返 时 间 ， 第 一 次 和 第 二 次 请 求 的 性 能 差距 只 会 加 大 。 大 家 可 以 
练习 一 下 ， 试 试 不 同 的 往返 时 间 会 有 什么 结果 。 理 解 了 TCP 拥塞 控制 机 制 后 ， 针 对 
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keep-alive、 流 水 线 和 多 路 复 用 的 优化 就 简单 得 多 了 。 





增 大 TCP 的 初始 拥塞 窗口 
把 服务 器 的 初始 cwnd 值 增 大 到 REFC 6928 新 规定 的 10 段 (IW10)， 是 提升 用 户 体 
验 以 及 所 有 TCP 应 用 性 能 的 最 简单 方式 。 好 消息 是 ， 很 多 操作 系统 已 经 更 新 了 内 
核 ， 采 用 了 增 大 后 的 值 。 可 以 留意 相应 的 文档 和 发 布 说 明 。 
在 Linux 上 , TIW10 是 2.6.39 以 上 版 本 内 核 的 新 默认 值 。 但 不 要 就 此 满足 ， 升 级 到 
3.2 以 上 版 本 还 有 其 他 重要 更 新 ， 比 如 2.2.3 节 的 “TCP 比例 降 速 ”。 











2.2.3 拥塞 预防 

认识 到 TCP 调节 性 能 主要 依赖 丢 包 反馈 机 制 非常 重要 。 换 名 话说 ， 这 不 是 一 个 假 
设 命 题 ， 而 是 一 个 具体 何 时 发 生 的 命题 。 慢 启动 以 保守 的 窗口 初始 化 连接 ， 随 后 的 
每 次 往返 都 会 成 倍 提高 传输 的 数据 量 ， 直 到 超过 接收 端的 流量 控制 窗口 ， 即 系统 
配置 的 拥塞 国 值 (ssthresh) 窗口 ， 或 者 有 分 组 丢失 为 止 ， 此 时 拥塞 预防 算法 介入 
(图 2-3)。 


拥塞 预防 算法 把 丢 包 作为 网 络 拥塞 的 标志 ， 即 路 径 中 其 个 连接 或 路 由 器 已 经 拥堵 了 ， 
以 至 于 必须 采取 删 包 措 施 。 因 此 ， 必 须 调 整 窗 口 大 小 ， 以 避免 造成 更 多 的 包 丢 失 ， 
从 而 保证 网 络 畅通 。 


重 置 拥塞 窗口 后 ， 拥 塞 预防 机 制 按 照 自己 的 算法 来 增 大 窗口 以 尽量 避免 丢 包 。 革 个 
时 刻 ， 可 能 又 会 有 包 丢 失 ， 于 是 这 个 过 程 再 从 头 开 始 。 如 有 果 你 看 到 过 TCP 连接 的 吞 
吐 量 跟踪 曲线 ， 发 现 该 曲线 呈 锯 齿 状 ， 那 现在 就 该 明白 为 什么 了 。 这 是 拥塞 控制 和 
预防 算法 在 调整 拥塞 窗口 ， 进 而 消除 网 络 中 的 丢 包 问题 。 


值得 一 提 的 是 ， 改 进 拥 塞 控制 和 预防 机 制 既是 学 术 研 究 的 课题 ， 也 是 商业 研发 的 
方向 。 毕 竟 ， 有 那么 多 不 同 的 网 络 、 不 同 的 数据 传输 方式 需要 适应 。 今 天 ， 你 的 
平台 中 可 能 运行 着 下 列 诸多 TCP 版 本 中 的 一 个 : TCP Tahoe 和 Reno (最 早 的 实 
现 )、TCP Vegas、TCP New Reno、TCP BIC、TCP CUBIC (Linux 的 默认 实现 ) 或 
Compound TCP (Windows 的 默认 实现 ) ， 等 等 。 然 而 无 论 你 使 用 哪 一 个 ， 拥 塞 控制 
和 预防 对 网 络 性 能 的 影响 都 是 存在 的 。 








TCP 比例 降 速 


确定 去 包 恢 复 的 最 优 方 式 并 不 容易 。 如 果 太 激进 ， 那 么 间歇 性 的 去 包 就 会 对 整个 
连接 的 吞吐 量 造 成 很 大 影响 。 而 如 果 不 够 快 ， 那么 还 会 继续 造成 更 多 分 组 丢失 。 
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最 初 ，TCP 使 用 AIMD (Multiplicative Decrease and Additive Increase， 倍 减 加 增 ) 
算法 ， 即 发 生 丢 包 时 ， 先 将 拥塞 窗口 减 半 ， 然 后 每 次 往返 再 缓慢 地 给 窗口 增加 一 
个 固定 的 值 。 不 过 ， 很 多 时 候 AIMD 算法 太 过 保守 ， 因 此 又 有 了 新 的 算法 。 

PRR (Proportional Rate Reduction， 比 例 降 速 ) 就 是 RFC 6937 规定 的 一 个 新 算法 ， 
其 目标 就 是 改进 丢 包 后 的 恢复 速度 。 改 进 效果 如 何 呢 ? 根据 谷歌 的 测量 ， 实 现 新 
算法 后 ， 因 丢 包 造成 的 平均 连接 延迟 减少 了 3%~10%。 


PRR 现在 是 Linux 3.2+ 内 核 默认 的 拥塞 预防 算法 。 这 又 是 你 升级 服务 器 的 一 个 
理由 | 








2.3 ”带宽 延迟 积 
TCP 内 置 的 拥塞 控制 和 预防 机 制 对 性 能 还 有 男 一 个 重要 彩 响 ， 发 送 端 和 接收 端 理想 
的 窗口 大 小 ， 一 定 会 因 往返 时 间 及 目标 传输 速率 而 变化 。 


为 什么 ? 我 们 知道 ， 发 送 端 和 接收 端 之 间 在 途 未 确认 的 最 大 数据 量 ， 取 决 于 拥塞 窗 
口 (cwnd) 和 接收 窗口 (rwnd) 的 最 小 值 。 接 收 窗口 会 随 每 次 ACK 一 起 发 送 ， 而 
0 由 发 送 端 根据 拥塞 控制 和 预防 算法 动态 调整 。 


无 论 发 送 端 发 送 的 数据 还 是 接收 端 接收 的 数据 超过 了 未 确认 的 最 大 数据 量 ， 都 必须 停 
下 来 等 待 另 一 方 ACK 确认 某 些 分 组 才能 继续 。 要 等 待 多 长 时 间 呢 ? 取决 于 往返 时 间 ! 








。 BDP (Bandwidth-delay product， 和 
数据 链 路 的 容量 与 其 端 到 端 延 迟 的 乘积 。 这 个 结果 就 是 任意 时 刻 处 于 在 途 未 确认 
状态 的 最 大 数据 量 。 


发 送 端 或 接收 端 无 论 谁 被 迫 频繁 地 停止 等 待 之 前 分 组 的 ACK， 都 会 造成 数据 缺口 
(图 2-7)， 从 而 必然 限制 连接 的 最 大 否 吐 量 。 为 解决 这 个 问题 ， 应 该 让 窗口 足够 大 ， 
以 保证 任何 一 端 都 能 在 ACK 返回 前 持续 发 送 数据 。 只 有 传输 不 中 断 ， 才 能 保证 最 
大 否 吐 量 。 而 最 优 窗口 大 小 取决 于 往返 时 间 ! 无 论 实际 或 通告 的 带宽 是 多 大 ， 窗 口 
过 小 都 会 限制 连接 的 吞吐 量 。 






































2-7: 拥塞 窗口 小 导致 数据 缺口 
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那么 ， 流 量 控制 窗口 (rwnd) 和 拥塞 控制 窗口 (cwnd) 的 值 多 大 合适 呢 ? 实际 上 ， 计 
算 过 程 很 简单 。 首 先 ， 假 设 cwnd 和 rwnd 的 最 小 值 为 16 KB ， 往 返 时 间 为 100 ms : 


16 KB = (16 x 1024 x 8) = 131 072 bit 


_131072 bit  _ ] 310720 bit/s 
0.1 S 
1 310 720 
it/s = 一 一 一 一 一 =1.31 Mbit 
1 310 720 bit/s 1 000 000 it/s 


不 管 发 送 端 和 接收 端的 实际 带宽 多 大 ， 这 个 TCP 连接 的 数据 传输 速率 不 会 超过 1.31 
Mbit/s ! 想 提高 吞吐 量 ， 要 么 增 大 最 小 窗口 值 ， 要 么 减少 往返 时 间 。 


类 似 地 ， 知 道 往返 时 间 和 两 端的 实际 带宽 也 可 以 计算 最 优 窗口 大 小 。 这 一 次 我 们 
假设 往返 时 间 不 变 (还 是 100 ms)， 发 送 端的 可 用 带宽 为 10 Mbit/s， 接 收 端 则 为 
100 Mbit/s+。 还 假设 两 端 之 间 没 有 网 络 拥塞 ,我 们 的 目标 就 是 充分 利用 客户 端的 10 
Mobit/s 带宽 : 


过 





10 Mbit/s = 10 x 1000000 = 10 000000 bit/s 
10 000 000 
it/s = 一 一 一 一 =1221 KB/s 
10 000 000 bit/s 8 x 1024 


1221 KB/sx0.1s =122.1 KB 


窗口 至 少 需要 122.1 KB 才能 充分 利用 10 Mbits 带宽 ! 还 记得 吗 ， 如 果 没 有 “窗口 
缩放 (RFC 1323)”，TCP 接收 窗口 最 大 只 有 64 KB 。 是 不 是 该 好 好 查 查 自己 的 客户 
端 和 服务 器 设置 啦 ? 


好 在 窗口 大 小 的 协商 与 调节 由 网 络 栈 自 动 控制 ， 应 该 会 自动 调整 。 但 尽管 如 此 ， 窗 
口 大 小 有 时 候 仍 然 是 TCP 性 能 的 限制 因素 。 如 果 你 怎么 也 想 不 通 在 高 速 连接 的 客户 
端 与 服务 器 之 间 ， 实 际 传 输 速度 只 有 可 用 带宽 的 几 分 之 一 ， 那 窗口 大 小 很 可 能 就 是 
罪魁 祸首 。 要么 因为 某 一 饱和 端 通告 的 接收 窗口 很 小 ， 要 么 因为 网 络 拥 塔 和 丢 包 导 
致 拥塞 窗口 重 置 ， 更 可 能 因为 流量 增长 过 快 导 致 对 连接 吞吐 量 施加 了 限制 。 

















高 速 局 域 网 中 的 带宽 延迟 积 
BDP 是 往返 时 间 和 目标 传输 速度 的 函数 。 因 此 ， 往 返 时 间 不 仅 在 高 传输 延迟 中 是 
一 个 常见 的 疙 颈 ， 就 算 在 LAN 中 也 可 能 是 一 个 瓶颈 | 
要 想 在 1 ms 的 往返 时 间 内 达到 1 GBit/s 的 传输 速度 ， 拥 塞 窗口 同样 至 少 要 有 122 
KB。 计 算 过 程 与 前 面 类 似 ， 只 不 过 要 给 目标 速度 多 加 几 个 震 ， 再 从 往返 时 间 中 拿 
掉 同样 多 个 替 而 已 。 














2.4 队 首 阻塞 


TCP 在 不 可 靠 的 信道 上 实现 了 可 靠 的 网 络 传输 。 基 本 的 分 组 错误 检测 与 纠正 、 按 
序 交 付 、 丢 包 重 发 ， 以 及 保证 网 络 最 高 效率 的 流量 控制 、 拥 塞 控制 和 预防 机 制 ， 让 
TCP 成 为 大 多 数 网 络 应 用 中 最 常见 的 传输 协议 。 


虽然 TCP 很 流行 ， 但 它 并 不 是 唯一 的 选择 ， 而 且 在 某 些 情况 下 也 不 是 最 佳 的 选择 。 
特别 是 按 序 交 付 和 可 靠 交 付 有 时 候 并 不 必要 ， 反 而 会 导致 额外 的 延迟 ， 对 性 能 造成 
负面 影响 。 


要 理解 为 什么 ， 可 以 想 一 想 ， 每 个 TCP 分 组 都 会 带 着 一 个 唯一 的 序列 号 被 发 出 ， 而 
所 有 分 组 必须 按 顺 序 传 送 到 接收 端 (图 2-8) 。 如 果 中 途 有 一 个 分 组 没 能 到 达 接 收 
端 ， 那 么 后 续 分 组 必须 保存 在 接收 端的 TCP 缓冲 区 ， 等 待 丢 失 的 分 组 重 发 并 到 达 接 
收 端 。 这 一 切 都 发 生 在 TCP 层 ， 应 用 程序 对 TCP 重 发 和 缓冲 区 中 排队 的 分 组 一 无 所 
知 ， 必 须 等 待 分 组 全 部 到 达 才 能 访问 数据 。 在 此 之 前 ， 应 用 程序 只 能 在 通过 套 接 字 
读数 据 时 感觉 到 延迟 交付 。 这 种 效应 称 为 TCP 的 队 首 (HOL，Head of Line) 阻塞 。 





























发 送 端 接收 端 







TCP 缓 冲 区 ， 
receive() ->nil 








3 个 TCP 段 





TCP 缓 冲 区 
receive() -> P1, P2, P3 

















图 2-8: TCP 队 首 阻塞 


队 首 阻塞 造成 的 延迟 可 以 让 我 们 的 应 用 程序 不 用 关心 分 组 重 排 和 重组 ， 从 而 让 代码 
保持 简洁 。 然 而 ， 代 码 简洁 也 要 付出 代价 ， 那 就 是 分 组 到 达 时 间 会 存在 无 法 预知 的 
延迟 变化 。 这 个 时 间 变 化 通常 被 称 为 封 动 ， 也 是 影响 应 用 程序 性 能 的 一 个 主要 因素 。 
另外 ， 有 些 应 用 程序 可 能 并 不 需要 可 靠 的 交付 或 者 不 需要 按 顺 序 交 付 。 比 如 ， 每 个 
分 组 都 是 独立 的 消息 ， 那 么 按 顺 序 交 付 就 没有 任何 必要 。 而 且 ， 如 果 每 个 消息 都 会 
覆盖 之 前 的 消息 ， 那 么 可 靠 交 付 同样 也 没有 必要 了 了。 可惜 的 是 ，TCP 不 支持 这 种 情 
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况 ， 所 有 分 组 必须 按 顺 序 交 付 。 


无 需 按 序 交 付 数据 或 能 够 处 理 分 组 丢失 的 应 用 程序 ， 以 及 对 延迟 或 抖动 要 求 很 高 的 
应 用 程序 ， 最 好 选择 UDP 等 协议 。 








丢 包 就 丢 包 
事实 上 ， 丢 包 是 让 TCP 达到 最 佳 性 能 的 关键 。 被 删除 的 包 恰恰 是 一 种 反馈 i 机制， 
能 够 让 接收 议和 发 送 端 各 自 调整 速度 ， 以 避免 网 络 拥堵 ， 同 时 保持 延迟 最 短 ( 参 
见 1.2 节 的 “本 地 路 由 器 的 缓冲 区 爆满 ”") 。 另 外 ， 有 些 应 用 程序 可 以 容忍 丢失 一 
定数 量 的 包 ， 比 如 语音 和 游戏 状态 通信 ， 就 不 需要 可 靠 传输 或 按 序 交 付 。 
就 算 有 个 包 丢 了 ， 音 频 编 解码 器 只 要 在 音频 中 插入 一 个 小 小 的 间歇 ， 就 可 以 继续 
处 理 后 来 的 包 。 只 要 间歇 够 小 ， 用 户 就 注意 不 到 ， 而 等 待 丢 失 的 包 则 可 能 导致 音 
频 输 出 产生 无 法 预料 的 暂停 。 相 对 来 说 ， 后 者 的 用 户 体验 更 糟糕 。 
类 似 地 ， 更 新 3D 游戏 中 角色 的 状态 也 一 样 : 收 到 工时 刻 的 和 包 而 等 待 工 1 时 刻 的 
包 通 常 毫 无 必要 。 理 想 情 况 下 ， 应 该 可 以 接收 所 有 状态 更 新 ， 但 为 避免 游戏 延迟 ， 
间歇 性 的 丢 包 也 是 可 以 接受 的 。 








2.5 针对 TCP 的 优化 建议 


TCP 是 一 个 自 适 应 的 、 对 所 有 网 络 节 点 一 视 同 仁 的 、 最 大 限制 利用 底层 网 络 的 协 
议 。 因 此 ， 优 化 TCP 的 最 佳 途径 就 是 调整 它 感知 当前 网 络 状况 的 方式 ， 根 据 它 之 上 
或 之 下 的 抽象 层 的 类 型 和 需求 来 改变 它 的 行为 。 无 线 网 络 可 能 需要 不 同 的 拥塞 算法 ， 
而 某 些 应 用 程序 可 能 需要 自 定义 服务 品质 (QoS，Quality of Service) 的 含义 ， 从 而 
交付 最 佳 的 体验 。 


不 同 应 用 程序 需求 间 的 复杂 关系 ， 以 及 每 个 TCP 算法 中 的 大 量 因素 ， 使 得 TCP 调 优 
成 为 学 术 和 商业 研究 的 一 个 “无 底 洞 "。 本 章 只 晴 峰 点 水 般 地 介绍 了 影响 TCP 性 能 
的 儿 个 典型 因素 ， 而 没有 探讨 的 选择 性 应 答 (SACK)、 延 迟 应 答 、 快 速 转发 等 ， 

便 一 个 都 能 让 你 领略 到 TCP 的 复杂 性 (或 者 乐趣 )， 感 受到 理解 、 分 析 和 调 优 之 难 。 


尽管 如 此 ， 而 且 每 个 算法 和 反馈 机 制 的 具体 细 市 可 能 会 继续 发 展 ， 但 核心 原理 以 及 
它们 的 影响 是 不 变 的 : 


























。 TCP 三 次 握手 增加 了 整整 一 次 往返 时 间 ， 

。 TCP 慢 启 动 将 被 应 用 到 每 个 新 连接 ; 

。 TCP 流量 及 拥塞 控制 会 影响 所 有 连接 的 吞吐 量 ; 
。 TCP 的 吞吐 量 由 当前 拥塞 窗口 大 小 控制 。 
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结果 ， 现 代 高 速 网 络 中 TCP 连接 的 数据 传输 速度 ， 往 往 会 受到 接收 端 和 发 送 端 之 
间 往 返 时 间 的 限制 。 男 外 ， 尽 管 带 宽 不 断 增长 ， 但 延迟 依旧 受 限于 光速 ， 而 且 已 经 
限定 在 了 其 最 大 值 的 一 个 很 小 的 常数 因子 之 内 。 大 多 数 情 况 下 ，TCP 的 瓶颈 都 是 延 
迟 ， 而 非 带宽 (参见 图 2-5)。 











2.5.1 服务 器 配置 调 优 

在 着 手 调整 TCP 的 缓冲 区 、 超 时 等 数 十 个 变量 之 前 ， 最 好 先 把 主机 操作 系统 升级 到 
最 新 版 本 。TCP 的 最 佳 实践 以 及 影响 其 性 能 的 底层 算法 一 直 在 与 时 俱 进 ， 而 且 大 多 
数 变化 都 只 在 最 新 内 核 中 才 有 实现 。 一 句 话 ， 让 你 的 服务 器 跟 上 时 代 是 优化 发 送 端 
和 接收 端 TCP 栈 的 首要 措施 。 


























表面 看 来 ， 升 级 服务 器 内 核 到 最 新 版 本 好 像 是 件 易 如 反 泡 的 事 儿 。 但 在 实 
心 。 践 中 ， 升 级 经 常会 遭遇 阻力 。 很 多 现 有 服务 器 已 经 针对 特定 的 内 核 版 本 进 
， 行 了 调 优 ， 而 系统 管理 员 并 不 情愿 升级 。 
实事 求 是 地 讲 ， 每 一 次 升级 都 有 相应 的 风险 。 但 为 了 获得 最 大 的 TCP 性 
能 ， 升 级 孔 怕 也 是 唯一 最 佳 的 选择 。 


























有 了 最 新 的 内 核 ， 我 们 推荐 你 遵循 如 下 最 佳 实践 来 配置 自己 的 服务 器 。 


。 增 大 TCP 的 初始 拥塞 窗口 
加 大 起 始 拥塞 窗口 可 以 让 TCP 在 第 一 次 往返 就 传输 较 多 数据 ， 而 随后 的 速度 提 
升 也 会 很 明显 。 对 于 突 发 性 的 短暂 连接 ， 这 也 是 特别 关键 的 一 个 优化 。 


。 慢 启 动 重启 
在 连接 空闲 时 禁用 慢 启动 可 以 改善 瞬时 发 送 数据 的 长 TCP 连接 的 性 能 。 


。 窗口 缩放 (RFC 1323 ) 
启用 窗口 缩放 可 以 增 大 最 大 接收 窗口 大 小 ， 可 以 让 高 延迟 的 连接 达到 更 好 知 
吐 量 。 

。 TCP 快 速 打开 
在 某 些 条 件 下 ， 人 允许 在 第 一 个 SYN 分 组 中 发 送 应 用 程序 数据 。TFO (TCP Fast 
Open，TCP 快速 打开 ) 是 一 种 新 的 优化 选项 ， 需 要 客户 端 和 服务 器 共同 支持 。 
为 此 ， 首 先 要 搞 清楚 你 的 应 用 程序 是 否 可 以 利用 这 个 特性 。 


以 上 儿 个 设置 再 加 上 最 新 的 内 核 ， 可 以 确保 最 佳 性 能 ， 每 个 TCP 连接 都 会 具有 较 低 
的 延迟 和 较 高 的 吞吐 量 。 
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视 应 用 程序 的 类 型 ， 可 能 还 有 必要 调整 服务 器 上 的 其 他 TCP 设置 ， 以 便 优 化 高 速 连 
接 的 速度 、 内 存 占用 ， 或 者 其 他 类 似 的 关键 选项 。 不 过 ， 这 些 系统 配置 与 平台 、 应 
用 程序 、 硬 件 有 关 ， 超 出 了 本 书 讨论 范围 ， 必 要 时 ， 可 以 参考 平台 文档 。 但 更 重要 
的 是 要 分 清 轻 重 缓急 ， 着 力 解决 真正 的 瓶颈 ， 而 不 是 眉毛 胡子 一 把 抓 。 





避 





Linux 用 户 可 以 使 用 ss 来 查看 当前 打开 的 套 接 字 的 各 种 统计 信息 。 在 命令 
a 行 里 运行 ss --options --extended --memory --processes --info， 可 以 看 
全 到 当前 通信 节点 以 及 它们 相应 的 连接 设置 。 



































2.5.2 ”应 用 程序 行为 调 优 
调 优 TCP 性 能 可 以 让 服务 器 和 客户 端 之 间 达 到 最 大 吞吐 量 和 最 小 延迟 。 而 应 用 程序 
如 何 使 用 新 的 或 已 经 建立 的 TCP 连接 同样 也 有 很 大 的 关系 。 


。 再 快 也 快 不 过 什么 也 不 用 发 送 ， 能 少 发 就 少 发 。 
。 我 们 不 能 让 数据 传输 得 更 快 ， 但 可 以 让 它们 传输 的 距离 更 短 。 
。 重用 TCP 连接 是 提升 性 能 的 关键 。 


当然 ， 消 除 不 必要 的 数据 传输 本 身 就 是 很 大 的 优化 。 比 如 ， 减 少 下 载 不 必要 的 资源 ， 
或 者 通过 压缩 算法 把 要 发 送 的 比特 数 降 到 最 低 。 然 后 ， 通 过 在 不 同 的 地 区 部 署 服务 
器 〈 比 如， 使 用 CDN) ， 把 数据 放 到 接近 客户 端的 地 方 ， 可 以 减少 网 络 往返 的 延迟 ， 
从 而 显著 提升 TCP 性 能 。 最 后 ， 尽 可 能 重用 已 经 建立 的 TCP 连接， 把 慢 启 动 和 其 
他 拥塞 控制 机 制 的 影响 降 到 最 低 。 





2.5.3 ”性 能 检查 清单 
优化 TCP 性 能 的 回报 是 丰厚 的 ， 无 论 什么 应 用 ， 性 能 提升 可 以 在 与 服务 器 的 每 个 连 
接 中 体现 出 来 。 下 面 几 条 请 大 家 务必 记 在 自己 的 日 程 表 里 : 


。 把 服务 器 内 核 升级 到 最 新 版 本 (Linux: 3.2+) ; 
。 确保 cwnd 大 小 为 10; 

。 禁用 空 闪 后 的 慢 启 动 ，; 

。 确保 启动 窗口 缩放 ， 

减少 传输 元 余数 据 ， 

压缩 要 传输 的 数据 

把 服务 器 放 到 离 用 户 近 的 地 方 以 减少 往返 时 间 ; 
。 尽 最 大 可 能 重用 已 经 建立 的 TCP 连接 。 
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UDP 的 构成 





1980 年 8 月 ， 紧 随 TCP/IP 之 后 ，UDP (User Datagram Protocol， 用 户 数据 报 协 议 ) 
被 John Postel 加 入 了 核心 网 络 协 议 套件 。 当 时 ， 正 值 TCP 和 IP 规 殉 分 立 为 两 个 单 
独 的 RFC。 这 个 时 间 点 非常 重要 ， 稍 后 我 们 会 看 到 ，UDP 的 主要 功能 和 亮点 并 不 
在 于 它 引 入 了 什么 特性 ， 而 在 于 它 包 略 的 那些 特性 。UDP 经 常 被 称 为 无 (Null) 协 
议 ，RFC 768 描述 了 其 运作 机 制 ， 全 文 完全 可 以 写 在 一 张 餐 巾 纸 上 。 


。 数据 报 
一 个 完整 、 独 立 的 数据 实体 ， 携 带 着 从 源 节 点 到 目的 地 节点 的 足够 信息 ， 对 这 些 
节点 间 之 前 的 数据 交换 和 传输 网 络 没 有 任何 依赖 。 


数据 报 (datagram) 和 分 组 (packet) 是 两 个 经 常 被 人 混用 的 词 ， 实 际 上 它们 还 是 
有 区 别 的 。 分 组 可 以 用 来 指 代 任何 格式 化 的 数据 块 ， 而 数据 报 则 通常 只 用 来 描述 那 
些 通过 不 可 靠 的 服务 传输 的 分 组 ， 既 不 保证 送 达 ， 也 不 发 送 失 败 通 知 。 正 因为 如 此 ， 
很 多 场合 下 人 们 都 把 UDP 中 User (用 户 ) 的 U， 改 成 Unreliable (不 可 靠 ) 的 U， 
于 是 UDP 就 成 了 “不 可 靠 数据 报 协议 ”(Unreliable Datagram Protocol) 。 这 也 是 为 
什么 把 UDP 分 组 称 为 数据 报 更 为 恰当 的 原因 。 


关于 UDP 的 应 用 ， 最 广为人知 同时 也 是 所 有 浏览 器 和 因特网 应 用 都 赖 以 运作 的 ， 就 
是 DNS (Domain Name System， 域 名 系统 )。DNS 负责 把 对 人 类 友好 的 主机 名 转换 
成 卫 地 址 。 可 是 ， 尽 管 浏 览 器 有 赖 于 UDP， 但 这 个 协议 以 前 从 未 被 看 成 网 页 和 应 
用 的 关键 传输 机 制 。HTTP 并 未 规定 要 使 用 TCP， 但 现实 中 所 有 HTTP 实现 (以 及 
构建 于 其 上 的 所 有 服务 ) 都 使 用 TCP。 
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不 过 ， 这 都 是 过 去 的 事 了 。IETF 和 W3C 工作 组 共同 制定 了 一 套 新 API 一 一 
WebRTC (Web Real-Time Communication，Web 实时 通信 )。WebRTC 着 眼 于 在 浏览 
器 中 通过 UDP 实现 原生 的 语音 和 视频 实时 通信 ， 以 及 其 他 形式 的 P2P (Peer-to-Peer， 








端 到 端 ) 通信 。 正 是 因 























为 WebRTC 的 出 现 ，UDP 作为 浏览 器 中 重要 传输 机 制 的 地 位 


才 得 以 突显 ， 而 且 还 有 了 浏览 器 API ! 本 书 将 在 第 18 章 再 探讨 WebRTC， 本 章 我 们 
先 来 介绍 一 下 UDP 协议 的 工作 原理 ， 搞 清楚 为 什么 以 及 什么 时 候 会 用 到 它 。 


3.1 无 协议 服务 


要 理解 为 什么 UDP 被 人 称 作 “无 协议 ”， 必 须 从 作为 TCP 和 UDP 下 一 层 的 卫 协议 


说 起 。 








IP 层 的 主要 任务 so 为 此 ， 消 息 会 被 封 


装 在 一 个 IP 分 组 内 (图 





-1)， 基 中 载 明 了 源 地 址 和 目标 地 址 ， 以 及 其 他 一 些 路 由 参 





i 个 重要 的 信息 : IP 层 不 保证 消息 可 靠 的 交付 ， 也 
不 发 送 失 败 通知 ， 实 际 上 是 把 底层 网 络 的 不 可 靠 性 直接 暴露 给 了 上 一 层 。 0 





路 由 节点 因为 网 络 拥塞 、 








负载 过 高 或 其 他 原因 而 删除 了 IP 分 组 ， 那 么 在 必要 的 情 : 


下 ,IP 的 上 一 层 协议 要 负责 检测 、 恢 复 和 重 发 数据 。 
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96 | 源 IP 地 址 
| 128 | 目标 IP 地 址 


可 选项 (如果 有 的 话 ) 


EE 和 | 








图 3-1: IPv4 首部 (20 字 节 ) 

UDP 协议 会 用 自己 的 分 组 结构 (图 3-2) 封装 用 户 消 息 ， 它 只 增加 了 4 个 字段 : 源 
端口 、 目 标 端 口 、 分 组 长 度 和 校 验 和 。 这 样 ， 当 IP 把 分 组 送 达 目标 主机 上 时， 该 主机 
能 够 拆 开 UDP 分 组 ， 根 据 目 标 端口 找到 目标 应 用 程序 ， 然 后 再 把 销 息 发 送 过 去 。 仅 


此 而 已 。 











| 


























3-2: UDP 首部 (8 字 节 ) 





事实 上 ，UDP 数据 报 中 的 源 端口 和 校 验 和 字段 都 是 可 选 的 。 了 P 分 组 的 首部 也 有 校 验 
和 ， 应 用 程序 可 以 忽略 UDP 校 验 和 。 也 就 是 说 ， 所 有 错误 检测 和 错误 纠正 工作 都 可 
以 委托 给 上 层 的 应 用 程序 。 说 到 底 ，UDP 仅仅 是 在 卫 层 之 上 通过 骨 入 应 用 程序 的 
源 端口 和 目标 端口 ， 提 供 了 一 个 “应 用 程序 多 路 复 有 用” 机制。 明白 了 这 一 点 ， 就 可 
以 总 结 一 下 UDP 的 无 服务 是 怎么 回 事 了 。 








。 不 保证 消息 交付 
不 确认 ， 不 重 传 ， 无 超时 。 


。 不 保证 交付 顺序 
不 设置 包 序号 ， 不 重 排 ， 不 会 发 生 队 首 阻塞 。 


。 不 跟踪 连接 状态 
不 必 建 立 连 接 或 重启 状态 机 。 


。 不 需要 拥塞 控制 
不 内 置 客户 端 或 网 络 反 馈 机 秆 


TCP 是 一 个 面向 字 市 流 的 协议 ， 能 够 以 多 个 分 组 形式 发 送 应 用 程序 消息 ， 且 对 分 组 
中 的 消息 范围 没有 任何 明确 限制 。 因 此 ， 连 接 的 两 端 存在 一 个 连接 状态 ， 每 个 分 组 
都 有 序号 ， 丢 失 还 要 重 发 ， 并 且 要 按 顺 序 交 付 。 相 对 来 说 ，UDP 数据 报 有 明确 的 限 
制 : 数据 报 必 须 封 装 在 耳 分 组 中 ， 应 用 程序 必须 读 取 完 整 的 消息 。 换 名 话说 ， 数 据 
报 不 能 分 片 。 


UDP 是 一 个 简单 、 无 状态 的 协议 ， 适 合作 为 其 他 上 层 应 用 协议 的 辅助 。 实 际 上 ， 这 
个 协议 的 所 有 决定 都 需要 由 上 层 的 应 用 程序 作出 。 不 过 ， 在 急 着 去 实现 一 个 协议 来 
扮演 TCP 的 角色 之 前 ， 你 还 应 该 认真 想 一 想 这 里 涉及 的 复杂 细节 ， 比 如 UDP 要 与 
很 多 中 间 设 备 打交道 (NAT 穿 透 )， 再 想 一 想 设 计 网 络 协议 的 那些 最 佳 实践 。 如 果 
没有 周密 的 设计 和 规划 ， 一 流 的 构想 也 可 能 沦 为 二 流 的 TCP 实现 。TCP 中 的 算法 和 
状态 机 已 经 经 过 了 几 十 年 的 磨合 与 改进 ， 而 且 吸 收 几 十 种 并 不 那么 容易 重新 实现 的 
机 制 。 
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3.2 UDP 与 网 络 地 址 转换 器 


令 人 遗憾 的 是 ，IPv4 地 址 只 有 32 位 长 ， 因 而 最 多 只 能 提供 42.9 亿 个 唯一 IP 地 址 。 
1990 年 代 初 ， 互 联网 上 的 主机 数量 呈 指 数 级 增长 ， 但 不 可 能 所 有 主机 都 分 配 一 个 唯 
一 的 卫 地 址 。1994 年 ， 作 为 解决 IPv4 地 址 即将 耗 尽 的 一 个 临时 性 方案 ， 卫 网 络 地 
址 转换 器 (NAT，Network Address Translator) 规范 出 台 了 ， 这 就 是 RFC 1631。 


建议 的 IP 重用 方案 就 是 在 网 络 边缘 加 入 NAT 设备 ， 每 个 NAT 设备 负责 维护 一 个 
表 ， 表 中 包含 本 地 IP 和 端口 到 全 球 唯 一 (外 网 ) IP 和 端口 的 映射 (图 3-3) 。 这 样 ， 
NAT 设备 背后 的 IP 地 址 空间 就 可 以 在 各 种 不 同 的 网 络 中 得 到 重用 ， 从 而 解决 地 址 
耗 尽 问题 。 













50.76.44.114:31454 


173.230.151.99:80 


192.168.0.1 1337 50.76.44.114 31454 














图 3-3: IP 网 络 地 址 转换 器 


然而 ， 这 个 临时 性 的 方案 居然 就 那么 一 直 沿 用 了 下 来 (这 种 现象 倒 也 不 鲜 见 )。 新 增 
的 NAT 设备 不 仅 立 杆 见 影 地 解决 了 地 址 耗 尽 问题 ， 而 且 迅 速成 为 很 多 公司 及 家 庭 
代理 和 路 由 器 、 安 全 装置 、 防 火 墙 ， 以 及 其 他 许多 硬件 和 软件 设备 中 的 内 置 组 件 。 
NAT 不 再 是 个 临时 性 方案 ， 它 已 经 成 了 因特网 基础 设施 的 一 个 组 成 部 分 。 





保留 的 私有 网 络 地 址 范围 
作为 监管 全 球 全 地 址 分 配 的 机 构 , IANA (Internet Assigned Numbers Authority， 
因特网 号 码 分 配 机 构 ) 为 私有 网 络 保留 了 三 段 全 地址， 这 些 全 地址 经 常 可 以 在 
NAT 设备 后 面 的 内 网 中 看 到 。 
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表 3-1; 保留 的 IP 地 址 范围 

IP 地 址 范围 地 址 数量 
10.0.0.0~10.255.255.255 16777 216 
172.16.0.0~172.31.255.255 1 048 576 
192.168.0.0~192.168.255.255 65 536 


其 中 一 段 (或 所 有 三 段 ) IP 地 址 是 不 是 很 眼熟 ? 在 你 的 局 域 风 中， 路 由 器 给 你 的 
计算 机 分 配 的 IP 地 址 很 可 能 位 于 其 中 一 段 。 这 个 地 址 就 是 你 在 内 网 中 的 私有 地 
址 。 在 需要 与 外 网 通信 时 ，NAT 设备 会 将 它们 转换 成 外 网 地 址 。 

为 防止 路 由 错误 和 引起 不 必要 的 麻烦 ， 不 允许 给 外 网 计算 机 分 配 这 些 保留 的 私有 
IP 地 址 。 














3.2.1 连接 状态 超时 
NAT 转换 的 问题 (至 少 对 于 UDP 而 言 ) 在 于 必须 维护 一 份 精确 的 路 由 表 才 能 保证 
数据 转发 。NAT 设备 依赖 连接 状态 ， 而 UDP 没有 状态 。 这 种 根本 上 的 错 配 是 很 多 
UDP 数据 报 传输 问题 的 总 根源 。 况 且 ， 客 户 端 前 面 有 很 多 个 NAT 设备 的 情况 也 不 
鲜 见 ， 问 题 由 此 进一步 恶化 了 。 


每 个 TCP 连接 都 有 一 个 设计 周密 的 协议 状态 机 ， 从 握手 开始 ， 然 后 传输 应 用 数据 ， 
最 后 通过 明确 的 信号 确认 关闭 连接 。 在 这 种 设计 下 ， 路 由 设备 可 以 监控 连接 状态 ， 
根据 情况 创建 或 删除 路 由 表 中 的 条 目 。 而 UDP 呢 ， 没 有 握手 ， 没 有 连接 终止 ， 实 际 
根本 没有 可 监控 的 连接 状态 机 。 


发 送出 站 UDP 不 费事 ， 但 路 由 响应 却 需要 转换 表 中 有 一 个 条 目 能 告诉 我 们 本 地 目标 
主机 的 IP 和 端口 。 因 此 ， 转 换 器 必须 保存 每 个 UDP 流 的 状态 ， 而 UDP 自身 却 没 有 
状态 。 


更 糟糕 的 是 ，NAT 设备 还 被 赋予 了 删除 转换 记录 的 责任 ,但 由 于 UDP 没有 连接 终 
止 确认 环 市 ， 任 何 一 端 随时 都 可 以 停止 传输 数据 报 ， 而 不 必 发 送 通 告 。 为 解决 这 个 
问题 ，UDP 路 由 记录 会 定时 过 期 。 定 时 多 长 ”没有 规定 ， 完 全 取决 于 转换 器 的 制造 
商 、 型 号 、 版 本 和 配置 。 因 此 ， 对 于 较 长 时 间 的 UDP 通信 ， 有 一 个 事实 上 的 最 佳 做 
法 ， 即 引入 一 个 双向 keep-alive 分 组 ， 周 期 性 地 重 置 传输 路 径 上 所 有 NAT 设备 中 转 
换 记录 的 计时 颖 。 
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TCP 超时 和 NAT 
从 技术 角度 讲 ，NAT 设备 不 需要 额外 的 TCP 超时 机 制 。TCP 协议 就 遵循 一 个 设计 
严密 的 握手 与 终止 过 程 ， 通 过 这 个 过 程 就 可 以 确定 何 时 需要 添加 或 删除 转换 记录 。 
遗憾 的 是 ， 实 际 应 用 中 的 NAT 设备 给 TCP 和 UDP 会话 应 用 了 类 似 的 超时 逻辑 。 
这 样 就 时 致 TCP 连接 有 时 候 也 需要 双向 keep-alive 分 组 。 如 果 你 的 TCP 连接 突然 
断 开 ， 那 很 有 可 能 就 是 中 间 NAT 超时 造成 的 。 











3.2.2 ”NAT 穿 透 

不 可 预测 的 连接 状态 处 理 是 NAT 设备 带 来 的 一 个 严重 问题 ， 但 更 为 严重 的 则 是 很 
多 应 用 程序 根本 就 不 能 建立 UDP 连接 。 尤 其 是 P2P 应 用 程序 ， 涉 及 VoIP、 游 戏 和 
文件 共享 等 ， 它 们 客户 端 与 服务 器 经 常 需要 角色 互 换 ， 以 实现 端 到 端的 双向 通信 。 


NAT 带 来 的 第 一 个 问题 ， 就 是 内 部 客户 端 不 知道 外 网 IP 地址， 只 知道 内 网 JP 地 
址 。NAT 负责 重 写 每 个 UDP 分 组 中 的 源 端 口 、 地 址 ， 以 及 卫 分 组 中 的 源 卫 地址 。 
如 果 客 户 端 在 应 用 数据 中 以 其 内 网 IP 地 址 与 外 网 主机 通信 ， 连 接 必然 失败 。 所 谓 的 
“透明 ”转换 因此 也 就 成 了 一 名 空话， 如 果 应 用 程序 想 与 私有 网 络 外 部 的 主机 通信 ， 
那么 它 首先 必须 知道 自己 的 外 网 IP 地址 。 


然而 ， 知 道外 网 他 地址 还 不 是 实现 UDP 传输 的 充分 条 件 。 任 何 到 达 NAT 设备 外 网 中 
的 分 组 还 必须 有 一 个 目标 端口 ， 而 且 NAT 转换 表 中 也 要 有 一 个 条 目 可 以 将 其 转换 为 内 
部 主机 的 卫 地 址 和 端口 号 。 如 果 没 有 这 个 条 目 (通常 是 从 外 网 传 数据 进来 )， 那 到 达 的 
分 组 就 会 被 删除 (图 3-4)。 此 时 的 NAT 设备 就 像 一 个 分 组 过 滤器 ， 除 非 用 户 通过 端口 
转发 (映射 ) 或 类 似 机 制 配置 过 ， 否 则 它 无 法 确定 将 . 分 组 发 送 给 哪 台 内 部 主机 。 


50.76.44.114:31454 、 


转换 表 173.230.151.99:20411 
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图 3-4: 由 于 没有 映射 规则 ， 入 站 分 组 直接 被 删除 
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需要 注意 的 是 ， 上 述 行为 对 客户 端 应 用 程序 不 是 问题 。 客 户 端 应 用 程序 基于 内 部 网 
络 实现 交互 ， 会 在 交互 期 间 建 立 必 要 的 转换 记录 。 不 过 ， 如 果 隔 着 NAT 设备 ， 那 
客户 端 ( 作 为 服务 器 ) 处 理 来 自 P2P 应 用 程序 (VoIP、 游 戏 、 文 件 共享 ) 的 入 站 连 
接 时 ， 就 必须 面 对 NAT 穿 透 问题 。 


为 解决 UDP 与 NAT 的 这 种 不 搭配 ， 人 们 发 明了 很 多 穿 透 技术 (TURN、STUN、 
ICE)， 用 于 在 UDP 主机 之 间 建 立 端 到 端的 连接 。 


3.2.3 STUN、TURN 与 ICE 


STUN (Session Traversal Utilities for NAT) 是 一 个 协议 (RFC 5389)， 可 以 让 应 用 
程序 发 现 网 络 中 的 地 址 转换 器 ， 发 现 之 后 进一步 取得 为 当前 连接 分 配 的 外 网 IP 地 址 
和 端口 (图 3-5)。 为 此 ， 这 个 协议 需要 一 个 已 知 的 第 三 方 STUN 服务 器 支持 ， 该 服 
务 器 必须 架设 在 公 网 上 。 









是 外 网 下 地 址 和 端口 吗 








IP: 50.76.44.114 端口 : 23123 





3TUN 服务 器 











3-5: STUN 查询 外 网 IP 地 址 和 端口 


假设 STUN 服务 器 的 全 地 址 已 知 (通过 DNS 查找 或 手工 指定 )， 应 用 程序 首先 向 
STUN 服务 器 发 送 一 个 绑 定 请 求 。 然 后 ，STUN 服务 器 返回 一 个 响应 ， 其 中 包含 在 外 
网 中 代表 客户 端的 卫 地 址 和 端口 号 。 这 种 简单 的 方式 解决 了 前 面 讨 论 的 一 些 癌 题 : 


。 应 用 程序 可 以 获得 外 网 卫 和 端口 ， 并 利用 这 些 信息 与 对 端 通信 ， 

。 发 送 到 STUN 服务 器 的 出 站 绑 定 请 求 将 在 通信 要 经 过 的 NAT 中 建立 路 由 条 目 ， 
使 得 到 达 该 卫 和 端口 的 入 站 分 组 可 以 找到 内 网 中 的 应 用 程序 

。 STUN 协议 定义 了 一 个 简单 keep-alive 探测 机 制 , 可 以 保证 NAT 路 由 条 目 不 超 时 。 


有 了 这 个 机 制 ， 两 台 主 机 端 需要 通过 UDP 通信 时 ， 它 们 首先 都 会 向 各 自 的 STUN 
服务 器 发 送 绑 定 请 求 ， 然 后 分 别 使 用 响应 中 的 外 网 IP 地 址 和 端口 号 交换 数据 。 


但 在 实际 应 用 中 ，STUN 并 不 能 适应 所 有 类 型 的 NAT 和 网 络 配置 。 不 仅 如 此 ， 某 些 
情况 下 UDP 还 会 被 防火 墙 或 其 他 网 络 设备 完全 屏蔽 。 这 种 情况 在 很 多 企业 网 很 常 
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见 。 为 解决 这 个 问题 ， 在 STUN 失败 的 情况 下 ， 我 们 还 可 以 使 用 TURN (Traversal 
Using Relays around NAT) 协议 (RFC 5766) 作为 后 备 。TURN 可 以 在 最 坏 的 情况 
下 跳 过 UDP 而 切换 到 TCP。 


TURN 中 的 关键 词 当然 是 中 继 (relay)。 这 个 协议 依赖 于 外 网 中 继 设 备 (图 3-6) 在 
两 端 间 传 递 数据 。 








中 继 服务 器 











3-6: TURN 中 继 服 务 器 


。 两 端 都 要 向 同一 台 TURN 服务 器 发 送 分 配 请 求 来 建立 连接 ,然后 再 进行 权限 协商 。 
。 协商 完毕 ， 两 端 都 把 数据 发 送 到 TURN 服务 器 ， 再 由 TURN 服务 器 转发 ， 从 而 
实现 通信 。 














很 明显 ， 这 就 不 再 是 端 对 端的 数据 交换 了 ! TURN 是 在 任何 网 络 中 为 两 端 提 供 连 接 
的 最 可 靠 方式 ， 但 运 维 TURN 服务 器 的 投入 也 很 大 。 至 少 ， 为 满足 传输 数据 的 需 
要 ， 中 继 设 备 的 容量 必须 足够 大 。 因 此 ， 最 好 在 其 他 直 连 手段 都 失败 的 情况 下 ， 再 
使 用 TURN。 





现实 中 的 STUN 和 TURN 


谷歌 的 libjingle 是 一 个 用 C++ 开发 的 用 于 构建 痛 到 端 应 用 程序 的 开源 库 ， 负 责 在 
后 台 实 现 STUN、TURN 和 ICE 协商。 谷歌 聊天 软件 Google Talk 使 用 的 就 是 这 个 
库 ， 其 文档 也 为 我 们 考量 现实 中 的 STUN 与 TURN 性 能 提供 了 有 价值 的 参考 : 

。 92% 的 时 间 可 以 直接 连接 (STUN); 

。 8% 的 时 间 要 使 用 中 继 器 (TURN ) 。 


由 于 NAT 设备 遍地 都 是 ， 相 当 一 部 分 用 户 不 能 通过 STUN 直接 建立 P2P 连接 。 
若 要 提供 可 靠 的 UDP 服务 ， 现 实 中 必须 同时 支持 STUN 和 TURN。 











构建 高 效 的 NAT 穿 透 方案 可 不 容易 。 好 在 ， 我 们 还 有 ICE (Interactive Connectivity 
Establishment) 协议 (RFC 5245)。ICE 规定 了 一 套 方法 ， 致 力 于 在 通信 各 端 之 间 建 立 一 
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条 最 有 效 的 通道 (图 3-7) : 能 直 连 就 直 连 ， 必 要 时 STUN 协商 ， 再 不 行使 用 TURN。 























STUN 服务 器 STUN 服务 器 











3-7: ICE 先后 尝试 直 连 、STUN 和 TURN 


实际 开发 中 ， 如 果 你 想 构建 基于 UDP 的 P2P 应 用 程序 ， 绝 对 应 该 选择 现 有 的 平台 
API， 或 者 实现 了 ICE、STUN 和 TURN 的 第 三 方 库 。 好 了 ， 了 解 了 这 些 协议 的 用 
途 之 后 ， 接 下 来 自然 就 要 考虑 安装 和 配置 了 ! 


3.3 针对 UDP 的 优化 建议 


UDP 是 一 个 简单 常用 的 协议 ， 经 常用 于 引导 其 他 传输 协议 。 事 实 上 ，UDP 的 特色 在 
于 它 所 省 略 的 那些 功能 : 连接 状态 、 握 手 、 重 发 、 重 组 、 重 排 、 拥 塞 控 制 、 拥 塞 预 
防 、 流 量 控制 ， 甚 至 可 选 的 错误 检测 ， 统 统 没 有 。 这 个 面向 消息 的 最 简单 的 传输 层 
在 提供 灵活 性 的 同时 ， 也 给 实现 者 带 来 了 麻烦 。 你 的 应 用 程序 很 可 能 需要 从 头 实现 
上 述 儿 个 或 者 大 部 分 功能 ， 而 且 每 项 功能 都 必须 保证 与 网 络 中 的 其 他 主机 和 协议 和 
谐 共存 。 


与 内 置 流量 和 拥塞 控制 以 及 拥塞 预防 的 TCP 不 同 ，UDP 应 用 程序 必须 自己 实现 这 
些 机 制 。 拥 塞 处 理 做 得 不 到 位 的 UDP 应 用 程序 很 容易 堵塞 网 络 ， 造 成 网 络 性 能 下 
降 ， 严 重 时 还 会 导致 网 络 拥塞 月 涡 。 如 果 你 想 在 自己 的 应 用 程序 中 使 用 UDP， 务必 
要 认真 研究 和 学 习 当 下 的 最 佳 实践 和 建议 。RFC 5405 就 是 这 么 一 份 文档 ， 它 对 设计 
单 播 UDP 应 用 程序 给 出 了 很 多 设计 建议 ， 简 述 如 下 : 


。 应 用 程序 必须 容忍 各 种 因特网 路 径 条 件 ; 
。 应 用 程序 应 该 控制 传输 速度 ， 

。 应 用 程序 应 该 对 所 有 流量 进行 拥塞 控制 ， 
。 应 用 程序 应 该 使 用 与 TCP 相近 的 带宽 
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。 应 用 程序 应 该 准备 基于 丢 包 的 重 发 计数 器 ， 

。 应 用 程序 应 该 不 发 送 大 于 路 径 MTU 的 数据 报 ; 

。 应 用 程序 应 该 处 理 数 据 报 丢 失 、 重 复 和 重 排 ; 

。 应 用 程序 应 该 足够 稳定 以 支持 2 分钟 以 上 的 交付 延迟 ，; 

。 应 用 程序 应 该 支持 IPv4 UDP 校 验 和 ， 必 须 支持 IPv6 校 验 和 ， 
。 应 用 程序 可 以 在 需要 时 使 用 keep-alive (最 小 间隔 15 秒 )。 


设计 新 传输 协议 必须 经 过 周密 的 考虑 、 规 划 和 研究 ， 否 则 就 是 不 负责 任 。 要 尽 可 能 
利用 已 有 的 库 或 框架 ,这 个 库 或 框架 应 该 考虑 了 NAT 穿 透 ， 而 且 能 够 与 其 他 并 发 
的 网 络 流量 和 谐 共 存 。 


我 很 高 兴 告 诉 大 家 : WebRTC 就 是 符合 这 些 要 求 的 框架 ! 
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传输 层 安 全 (TLS) 





SSL (Secure Sockets Layer， 安 全 套 接 字 层 ) 协议 最 初 是 网 景 公司 为 了 保障 网 上 交 
易 安 全 而 开发 的 ， 该 协议 通过 加 密 来 保护 客户 个 人 资料 ， 通 过 认证 和 完整 性 检查 来 
确保 交易 安全 。 为 达到 这 个 目标 ，SSL 协议 在 直接 位 于 TCP 上 一 层 的 应 用 层 被 实现 
(图 4-1)。SSL 不 会 影响 上 层 协议 (如 HTTP、 电 子 邮件 、 即 时 通讯 )， 但 能 够 保证 
上 层 协 议 的 网 络 通信 安全 。 
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图 4-1: 传输 层 安 全 (TLS) 


在 正确 使 用 SSL 的 情况 下 ， 第 三 方 监听 者 只 能 推断 出 连接 的 端点 、 加 密 类 型 ， 以 及 
发 送 数 据 的 频率 和 大 臻 数量， 不 能 实际 读 取 或 修改 任何 数据 。 
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增 所 


2 IETF 后 来 在 标准 化 SSL 协议 时 ， 将 其 改名 为 Transport Layer Security 
® 
‘0% 














。(TLS， 传 输 层 安全 )。 很 多 人 会 混用 TLS 和 SSL， 但 严格 来 讲 它们 并 不 相 
心 ， 同 ， 因 为 它们 指 代 的 协议 版 本 不 同 。 











SSL 2.0 是 该 协议 第 一 个 公开 发 布 的 版 本 ， 但 由 于 存在 很 多 安全 缺陷 很 快 就 被 SSL 
3.0 取代 。 鉴 于 SSL 协议 是 网 景 公 司 专 有 的 ，IETE 成 立 了 一 个 小 组 负责 标准 化 该 协 
议 ， 后 来 就 有 了 RFC 2246， 即 TLS 1.0， 也 就 是 SSL 3.0 的 升级 版 。 





本 协议 与 SSL 3.0 的 区 别 并 不 特别 明显 ， 但 这 些 区 别 会 严重 妨碍 TLS 1.0 与 
SSL3.0 之 间 的 互 操 作 性 。 


一 一 TLS 协议 (RFC 2246) 


TLS 1.0 自 1999 年 1 月 发 布 后 ， 为 解决 发 现 的 安全 缺陷 同时 扩展 协议 的 功能 ，IETF 
工作 组 先后 又 发 布 过 两 个 新 版 本 ， 2006 年 4 月 发 布 了 TLS 1.1，2008 年 8 月 发 布 了 
TLS 1.2。 从 内 部 来 看 ，SSL 3.0 实现 与 后 续 所 有 TLS 版 本 很 相似 ， 很 多 客户 端 到 今 
天 还 在 支持 SSL 3.0 和 TLS 1.0。 当 然 ， 要 保护 用 户 免 受 攻击 ， 最 好 还 是 升级 到 最 新 
版 本 。 





TLS 设计 的 初衷 是 在 可 靠 的 传输 协议 〈 如 TCP) 之 上 运行 。 可 是 ， 有 实现 

心 把 它 放 到 了 数据 报 协议 (如 UDP) 之 上 。RFC 6347， 即 DTLS (Datagram 

sy Transport Layer Security， 数 据 报 传输 层 安全 ) 就 虽 在 以 TLS 协议 为 基础 ， 
同时 兼顾 数据 报 交 付 模式 并 提供 类 似 的 安全 保障 。 





4.1 加密、 身份 验证 与 完整 性 


TLS 协议 的 目标 是 为 在 它 之 上 运行 的 应 用 提供 三 个 基本 服务 : 加密、 身份 验证 和 数 
据 完整 性 。 从 技术 角度 讲 ， 并 不 是 所 有 情况 下 都 要 同时 使 用 这 三 个 服务 。 比 如 ， 可 
以 接受 证 书 但 不 验证 其 真实 性 ， 而 前 提 是 你 非常 清楚 这 样 做 有 什么 安全 风险 且 有 防 
范 措 施 。 实 践 中 ， 安 全 的 web 应 用 都 会 利用 这 三 个 服务 。 





. 加 密 

混淆 数据 的 机 制 
。 身份 验证 

验证 身份 标识 有 效 性 的 机 制 
完整 性 


检测 消息 是 否 被 自 改 或 伪造 的 机 制 




















为 了 建立 加 密 的 安全 数据 通道 ， 连 接 双 方 必 须 就 加 密 数 据 的 密 钥 套件 和 密 钥 协 商 一 
致 。TLS 协议 规定 了 一 套 严 密 的 握手 程序 用 于 交换 这 些 信息 ， 相 关内 容 将 在 4.2 市 
“TLS 握手 ”中 介绍 。 担 手机 制 中 设计 最 巧妙 的 地 方 ， 就 是 其 使 用 的 公 钥 密码 系统 
(也 称 “ 非 对 称 密 钥 加 密 ”)， 这 套 系 统 可 以 让 通信 双方 不 必 事 先 “ 认 识 ” 即 可 商定 共 
享 的 安全 密 钥 ， 而 且 协 商 过 程 还 是 通过 非 加 密 通 道 完 成 的 。 


握手 过 程 中 ，TLS 协议 还 允许 通信 两 端 互 相 验 明正 身 。 在 浏览 器 中 ， 验 证 机 制 允 许 
客户 端 验 证 服务 器 就 是 它 想 联系 的 那个 (比如 ,银行 )， 而 不 是 通过 名 字 或 IP 地 址 伪 
装 的 目标 。 这 个 验证 首先 需要 建立 “认证 机 构 信任 链 ”(Chain of Trust and Certificate 
Authorities) 。 此 外 ， 服 务 器 也 可 以 选择 验证 客户 端的 身份 。 比 如 ， 公 司 的 代理 服务 器 
可 以 验证 所 有 雇员 ， 每 位 雇员 都 应 该 有 公司 签发 的 独一无二 的 认证 证 书 。 


除了 密 钥 协 商 和 身份 验证 ，TLS 协议 还 提供 了 自己 的 消息 分 帧 机 制 ， 使 用 MAC 
(Message Authentication Code， 消 息 认证 码 ) 签署 每 一 条 消息 。MAC 算法 是 一 个 单 
向 加 密 的 散 列 函数 (本质 上 是 一 个 校 验 和 )， 密 钥 由 连接 双方 协商 确定 。 只 要 发 送 
TLS 记录 ， 就 会 生成 一 个 MAC 值 并 附加 到 该 消息 中 。 接 收 端 通过 计算 和 验证 这 个 
MAC 值 来 判断 消息 的 完整 性 和 可 靠 性 。 


上 述 三 种 机 制 为 Web 通信 构建 了 一 个 安全 的 环境 。 所 有 现代 Web 浏览 器 都 支持 多 
种 加 密 套 件 ， 能 够 验证 客户 端 和 服务 器 ， 并 能 对 每 条 记录 进行 消息 完整 性 检查 。 



























































Web 代理 、 中 间 设 备 、TLS 与 新 协议 


HTTP 良好 的 扩展 能 力 和 获得 的 巨大 成 功 ， 使 得 Web 上 出 现 了 大 量 代理 和 中 间 设 
备 : 缕 存 服务 器 、 安 全 网 关 、Web 加 速 器 、 内 容 过 滤器 ， 等 等 。 有 时 候 ， 我 们 知 
道 这 些 设备 的 存在 〈 显 式 代理 ) ， 而 有 时 候 ， 这 些 设备 对 终端 用 户 则 完全 不 可 见 。 


然而 ， 这 些 服务 器 的 存在 及 成 功 也 给 那些 试图 脱离 HTTP 协议 的 人 带 了 一 些 不 便 。 
比如 ， 有 的 代理 服务 器 只 会 简单 地 转发 自己 无 法 解释 的 HTTP 扩展 或 其 他 在 线 格 
式 (wire format) ， 而 有 的 则 不 管 是 否 必 要 都 会 对 所 有 数据 执行 自己 设 定 的 逻辑 ， 
还 有 一 些 安全 设备 可 能 会 把 本 来 正常 的 数据 误 判 成 恶意 通信 。 

换 向 话说 ， 现 实 当 中 如 果 想 脱离 HTTP 和 80 端口 的 语义 行事 ， 经 常会 遭遇 各 种 部 
署 上 的 麻烦 。 比 如， 某 些 客户 总 表现 正常 ， 另 一 些 可 能 就 会 异常 ， 其 至 在 某 个 网 
段 表 现 正常 的 客户 痛 到 了 另 一 个 网 段 又 会 变 得 异常 。 

为 解决 这 些 问题 ， 出 现 了 一 些 新 协议 和 对 HTTP 的 扩展 ， 比 如 WebSocket、SPDY 
等 。 这 些 新 协议 一 般 要 依赖 于 建立 HTTPS 信道 ， 以 绕 过 中 间 代 理 ， 从 而 实现 可 靠 
的 部 署 ， 因 为 加 密 的 传输 信道 会 对 所 有 中 间 设 备 都 混 清 数据 。 这 样 虽然 解决 了 中 
间 设 备 的 问题 ， 但 却 导 致 通信 两 端 不 能 再 利用 这 些 中 间 设 备 ， 从 而 与 这 些 设备 提 
供 的 身份 验证 、 缓 存 、 安 全 扫描 等 功能 失之交臂。 
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你 或 许 一 直 想 不 通 为 什么 大 多 数 WebSocket 手册 都 告诉 你 要 使 用 HTTPS 向 移动 客 
户 端 发 送 数 据 ， 现 在 你 应 该 明白 了 。 随 着 时 间 推 移 ， 网 络 上 的 中 间 设 备 通过 升级 
也 开始 能 识别 新 协议 ， 基 于 HTTPS 部 署 的 要 求 也 将 逐渐 弱化 。 到 时 候 ， 除 非 你 的 
会 话 真 的 需要 TLS 提供 的 加 密 、 身 份 验 证 和 完整 性 检查 功能 ， 否 则 完全 可 以 不 用 
HTTPS ! 








4.2 TLS 握 手 


客户 端 与 服务 器 在 通过 TLS 交换 数据 之 前 ， 必 须 协 商 建立 加 密 信道 。 协 商 内 容 包 括 
TLS 版 本 、 加 密 套件 ， 必 要 时 还 会 验证 证 书 。 然 而 ， 协 商 过 程 的 每 一 步 都 需要 一 个 
分 组 在 客户 端 和 服务 器 之 间 往 返 一 次 (图 4-2)， 因 而 所 有 TLS 连接 启动 时 都 要 经 历 
一 定 的 延迟 。 























发 送 端 接收 端 





二 
SW959-d) 


swell- SU 








4-2: TLS 握手 协议 


好 a 
本 图 4-2 假设 “ 光 通 过 光纤 ”的 单程 时 间 都 是 28 ms， 也 就 是 前 面 TCP 连接 
避 4 ， 中 从 纽约 到 伦敦 之 间 的 时 间 ， 另 见 表 1-1。 

人 














。 0ms: TLS 在 可 靠 的 传输 层 (TCP) 之 上 运行 ， 这 意味 着 首先 必须 完成 TCP 的 “ 
次 握手 ”， 即 一 次 完整 的 往返 。 
。 56 ms: TCP 连接 建立 之 后 ， 客 户 端 再 以 纯 文本 形式 发 送 一 些 规格 说 明 ， 比 如 它 所 运 
行 的 TLS 协议 的 版 本 、 它 所 支持 的 加 密 套 件 列表 ， 以 及 它 支 持 或 希望 使 用 的 另外 一 
。 84 ms: 然后 ， 服 务 器 取得 TLS 协议 版 本 以 备 将 来 通信 使 用 ， 从 客户 端 提 供 的 加 密 
套件 列表 中 选择 一 个 ， 再 附 上 自己 的 证 书 ， 将 响应 发 送 回 客户 端 。 作 为 可 选项 ， 服 
务 器 也 可 以 发 送 一 个 请 求 ， 要 求 客户 端 提 供 证 书 以 及 其 他 TLS 扩展 参数 。 
。 112 ms: 假设 两 端 经 过 协商 确定 了 共同 的 版 本 和 加 密 套件 ， 客 户 端 也 高 高 兴 兴 地 
ee 然后 ， 客 户 端 会 生成 一 个 新 的 对 称 密 钥 ， 用 服务 
的 公 钥 来 加 密 ， 加 密 后 发 送 给 服务 器 ， 告 诉 服 务 器 可 以 开始 加 密 通 信 了 。 到 
a» 除了 用 服务 器 公 钥 加 密 的 新 对 称 密 钥 之 外 ， 所 有 数据 都 以 明文 形式 
发 送 。 
。 140 ms: 最 后 ， 服 务 器 解密 出 客户 端 发 来 的 对 称 密 钥 ， 通 过 验证 消息 的 MAC 检 
测 消 息 完整 性 ， 再 返回 给 客户 端 一 个 加 密 的 “Finished” 消 息 。 
。 168 ms: 客户 端 用 它 之 前 生成 的 对 称 密 钥 解密 这 条 消息 ， 验 证 MAC， 如 果 一 切 
顺利 ， 则 建立 信道 并 开始 发 送 应 用 数据 。 









































:es 
新 TLS 连接 要 完成 一 次 “完整 的 握手 ”需要 两 次 网 络 往返 。 另 外 ， 还 可 以 使 
心 4 、 用 “简短 担 手 ”"， 只 需 一 次 往返 ， 详 细 信 息 请 参见 4.3 节 “TLS 会 话 恢复 ”。 
[oa 
协商 建立 TLS 安全 信道 是 一 个 复杂 的 过 程 ， 很 容易 出 错 。 好 在 服务 器 和 浏览 器 会 殖 
我 们 做 好 这 些 工作 ， 我 们 要 做 的 就 是 提供 和 配置 证 书 ! 


总 之 ， 尽 管 我 们 的 Web 应 用 不 一 定 参与 上 述 过 程 ， 但 最 重要 的 是 知道 每 一 个 TLS 
连接 在 TCP 握手 基础 上 最 多 还 需要 两 次 额外 的 往返 。 这 些 都 会 增加 实际 交换 数据 之 
前 的 等 待 时 间 ! 如 果 考 虑 不 周 ， 通 过 TLS 交付 数据 很 可 能 会 引入 几 百 甚至 几 千 ms 
的 网 络 延迟 。 














公 钥 与 对 称 密 钥 加 密 的 性 能 
公 钥 加 密 系 统 (http://en.wikipedia.org/wiki/Public-key_cryptography) 只 在 建立 TLS 
信道 的 会 话 中 使 用 。 在 此 期 间 ， 服 务 器 向 客户 端 提供 它 的 公 钥 ， 客 户 端 生成 对 称 
密 铀 并 使 用 服务 器 的 公 角 对 其 加 密 ， 然 后 再 将 加 密 的 对 称 窗 钢 返回 服务 器 。 服务 
器 继而 用 自己 的 私 钥 解 密 出 客户 匣 发 来 的 对 称 密 钥 。 











传输 层 安全 (TLS) | 45 


接 下 来 ， 客 户 廊 与 服务 器 间 的 通信 就 全 都 使 用 客户 闸 生 成 的 共享 密 钥 加 密 ， 这 就 
是 对 称 密 钥 加 密 。 之 所 以 这 样 设计 ， 很 大 程度 上 是 出 于 性 能 考虑 ， 因 为 公 钥 加 密 
需要 很 大 的 计算 量 。 为 了 演示 两 者 的 差别 ， 假 如 你 的 电脑 上 安装 了 OpenSSL， 可 
以 试 试 以 下 两 条 命令 : 

。 $> openssl speed rsa 


。 $> openssl speed aes 


需要 注意 ， 这 两 条 命令 涉及 的 单位 不 能 直接 相 比 : RSA 测试 会 提供 一 个 摘要 表格 ， 
列 出 不 同 密 钥 大 小 每 秒 的 操作 数 ， 而 AES 性 能 通过 每 秒 的 字 节 数 来 度量 。 无 论 如 
何 ， 都 不 难看 出 RSA 操作 (完整 的 TLS 握手 ) 的 数量 ， 在 推荐 的 1024 或 2048 
位 的 密 钥 长 度 下 部 很 可 能 成 为 瓶颈 。 

实际 的 数值 可 能 会 因 硬件 、 核 心 数量 、TLS 版 本 、 服 务 器 配置 、 典 型 的 服务 负载 ， 
以 及 其 他 因素 不 同 而 有 很 大 差异 。 请 大 家 不 要 轻信 一 些 广告 宣传 或 过 时 的 测试 报 
告 ， 最 好 还 是 在 自己 的 硬件 上 运行 上 述 测 试 。 











4.2.1 应 用 层 协议 协商 (ALPN) 

理论 上 ， 网 络 上 的 任意 两 端 都 可 以 使 用 自 定义 的 协议 进行 通信 。 为 此 ， 需 要 提前 确 
定 使 用 什么 协议 、 指 定 端口 号 (HTTP 是 80，TLS 是 443)， 并 配置 所 有 客户 端 和 服 
务 器 使 用 它们 。 然 而 在 实践 中 ， 这 种 方法 效率 很 低 且 很 难 做 到 。 因 为 每 个 端口 都 必 
须 得 到 认可 ， 而 防火 墙 及 其 他 中 间 设 备 通常 只 人 允许 在 80 和 443 端口 上 通信 。 





于 是 ， 为 了 简化 自 定 义 协 议 的 部 署 ， 我 们 往往 必须 重用 80 或 443 端口 ， 再 通过 额 
外 的 机 制 协商 确定 协议 。80 端口 是 为 HTTP 保留 的 ， 而 HTTP 规范 还 专门 为 协商 协 
议 规定 了 一 个 Upgrade 首部。 可是， 使 用 Upgrade 需要 一 次 额外 的 往返 时 间 ， 且 由 
于 很 多 中 间 设 备 的 存在 ， 协 商 结果 也 不 可 靠 。 要 了 解 更 多 信息 ， 请 参考 4.1 节 中 的 
“Web 代理 、 中 间 设 备 、TLS 与 新 协议 ”。 
加 12.3.9 节 “ 有 效 的 HTTP 2.0 升级 与 发 现 ” 中 有 一 个 使 用 HTTP Upgrade 的 
4 4 ， 实 际 例子 。 

人 





解决 办 法 不 难 想象 ， 那 就 是 使 用 443 端口 ， 这 是 给 (运行 于 TLS 之 上 的 ) 安全 
HTTPS 会 话 保留 的 。 由 于 端 到 端的 加 密 信道 对 中 间 设 备 模糊 了 数据 ， 因 此 这 种 方式 
就 成 为 了 一 种 部 署 任意 新 应 用 协议 的 可 靠 而 快捷 的 方式 。 不 过 ， 虽 然 使 用 TLS 保障 
了 可 靠 性 ， 但 我 们 还 需要 一 种 机 制 来 协商 协议 。 


作为 HTTPS 会 话 ， 当 然 可 以 利用 HTTP 的 Upgrade 机 制 来 协商 ， 但 这 会 导致 一 次 额 
外 的 往返 ， 造 成 延迟 。 那 在 TLS 握手 的 同时 协商 确定 协议 可 行 吗 ? 
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顾名思义 ， 应 用 层 协议 协商 (ALPN，Application Layer Protocol Negotiation) 作为 
TLS 扩展 ， 让 我 们 能 在 TLS 握手 的 同时 协商 应 用 协议 (图 4-2)， 从 而 省 掉 了 HTTP 
的 upgrade 机 制 所 需 的 额外 往返 时 间 。 具 体 来 说 ， 整 个 过 程 分 如 下 几 步 : 











。 客户 端 在 clientHellto 消息 中 追加 一 个 新 的 ProtocolNameList 字段 ， 包 含 自己 支 
持 的 应 用 协议 ，; 

。 服务 器 检查 ProtocolNameList 字段 ， 并 在 serverHello 消息 中 以 ProtocolName 字 
段 返回 选中 的 协议 。 

服务 器 可 以 从 中 选择 一 个 协议 名 ， 否 则 如 果 不 支 持 其 中 的 任何 协议 ， 则 断 开 连 接 。 

只 要 TLS 握手 完成 、 建 立 了 加 密 信道 并 就 应 用 协议 达成 一 致 ， 客 户 端 与 服务 器 就 可 

以 立即 通信 。 




















A 


ALPN 抛 开 了 HTTP 的 Upgrade 机 制 ， 省 却 了 一 次 往返 的 延迟 。 不 过 ，TLS 
人 AS 4 ， 提 和 手 还 是 必需 的 。 事 实 上 ，ALPN 协商 不 会 比 基 于 非 加 密 信 道 的 HTTP 
尾 ，Upgrade 更 快 ， 它 只 能 保证 通过 TLS 进行 协议 协商 不 会 更 慢 。 














NPN 与 ALPN 的 渊源 


NPN (Next Protocol Negotiation， 下 一 代 协 议 协 商 ) 是 谷歌 在 SPDY 协议 中 开发 的 
一 个 TLS 扩展 ， 目 的 是 通过 在 TLS 握手 期 间 协 商 应 用 协议 来 提高 效率 。 听 着 耳 误 
吗 ? 最 终结 果 与 ALPN 功能 等 价 。 


ALPN 是 IETF 在 NPN 基础 上 修订 并 批准 的 版 本 。 在 NPN 中 ,服务 器 广播 自己 
支持 的 协议 ， 客 户 端 选择 和 确认 协议 。 而 在 ALPN 中 ， 交 换 次 序 颠 倒 过 来 了 ， 客 
户 茹 先 声 明 自 己 支持 的 协议 ,服务 器 选择 并 确认 协议 。 这 样 修改 的 目的 是 为 了 让 
ALPN 与 其 他 协议 协商 标准 保持 一 致 。 


挨 向 话说 ，ALPN 是 NPN 的 继任 者 ， 而 NPN 已 经 废弃 。 原 来 配置 为 使 用 NPN 的 
客户 痛 和 服务 器 ， 都 需要 重新 配置 升级 到 ALPN。 











4.2.2 ”服务 器 名 称 指 示 CSNI) 

网 络 上 可 以 建立 TCP 连接 的 任意 两 端 都 可 以 建立 加 密 TLS 信道 ， 客 户 端 只 需 知 道 
另 一 端的 IP 地 址 即 可 建立 连接 并 进行 TLS 握手 。 然 而 ， 如 果 服 务 器 想 在 一 个 IP 地 
址 为 多 个 站 点 提供 服务 ， 而 每 个 站 点 都 拥有 自己 的 TLS 证 书 ， 那 怎么 办 ? 这 问题 看 
似 有 点 怪 ， 但 其 实 一 点 都 不 怪 。 


为 了 解决 这 个 问题 ，SNI (Server Name Indication， 服 务 器 名 称 指示 ) 扩展 被 引入 
TLS 协议 ， 该 扩展 允许 客户 端 在 握手 之 初 就 指明 要 连接 的 主机 名 。Web 服务 器 可 以 
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检查 SNI 主机 名 ， 选 择 适 当 的 证 书 ， 继 续 完成 握手 。 








TLS、HTTP 及 专用 IP 
TLS+SNI 机 制 与 HTTP 中 发 送 Host 首部 是 相同 的 ， 只 不 过 后 者 是 客户 端 要 在 请 求 
中 包含 站 点 的 主机 名 。 总 之 ， 都 是 相同 的 卫 地 址 服务 于 不 同 的 域名 ， 而 区 分 不 同 
域名 的 手段 就 是 SNI 或 Host。 
遗憾 的 是 ， 很 多 旧版 本 的 客户 端 (Windows XP 上 的 大 多 数 IE、Android 2.2 等 平 
台 上 的 浏览 器 ) 都 不 支持 SNI。 如 果 你 想 与 这 些 旧版 本 的 客户 端 进行 TLS 通信 ， 
就 得 为 每 个 主机 准备 一 个 专用 IP 地 址 。 


4.3 TLS 会 话 恢 复 


完整 TLS 握手 会 带 来 额外 的 延迟 和 计算 量 ， 从 而 给 所 有 依赖 安全 通信 的 应 用 造成 严 
重 的 性 能 损失 。 为 了 挽回 某 些 损失 ，TLS 提供 了 恢复 功能 ， 即 在 多 个 连接 间 共 享 协 
商 后 的 安全 密 钥 。 


4.3.1 会 话 标识 符 

最 早 的 “会 话 标识 符 ”(Session Identifier，RFC 5246) 机 制 是 在 SSL 2.0 中 引入 的 ， 
支持 服务 器 创建 32 字 节 的 会 话 标识 符 ， 并 在 上 一 节 我 们 讨论 的 完整 的 TLS 协商 期 
间作 为 其 “ServerHello” 消 息 的 一 部 分 发 送 。 


在 内 部 ， 服 务 器 会 为 每 个 客户 端 保存 一 个 会 话 ID 和 协商 后 的 会 话 参 数 。 相 应 地 ， 客 
户 端 也 可 以 保存 会 话 ID 信息 ， 并 将 该 ID 包含 在 后 续 会 话 的 “ClientHello” 消 息 中 ， 
从 而 告诉 服务 器 自己 还 记 着 上 次 担 手 协商 后 的 加 密 套 件 和 密 钥 呢 ， 这 些 都 可 以 重用 。 
假设 客户 端 和 服务 器 都 可 以 在 自己 的 缓存 中 找到 共享 的 会 话 ID 参数 ， 那 么 就 可 以 进 
行 简短 握手 (图 4-3)。 否 则 ， 就 要 重新 启动 一 次 全 新 的 会 话 协商 ， 生 成 新 的 会 话 ID。 
借助 会 话 标 识 符 可 以 节省 一 次 往返 ， 还 可 以 省 掉 用 于 协商 共享 加 密 密 钥 的 公 钥 加 密 
计算 。 由 于 重用 了 之 前 协商 过 的 会 话 数据 ， 就 可 以 迅速 建立 一 个 加 密 连 接 ， 而 且 同 
样 安全 。 









































ee 实际 应 用 中 ， 大 多 数 Web 应 用 会 尝试 与 同一 个 主机 建立 多 个 连接 ， 以 便 并 
4、 行 取得 资源 。 在 这 种 情况 下 ， 会 话 恢复 就 成 为 减少 延迟 及 两 端 计 算 量 的 必 
必 ' 备 优化 手段 。 
大 多 数 现代 浏览 器 在 打开 到 相同 服务 器 的 新 连接 之 前 ， 都 会 有 意 等 待 第 一 
个 TLS 连接 完成 。 这 样 ， 后 续 的 TLS 连接 就 可 以 重用 第 一 个 SSL 会 话 ， 
从 而 避免 重新 握手 造成 的 损失 。 
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4-3: 简短 TLS 握手 协议 


由 于 服务 器 必须 为 每 个 客户 端 都 创建 和 维护 一 段 会 话 缓存 , “会 话 标识 符 ” 机 制 在 实 
践 中 也 会 遇 到 问题 ， 特 别 是 对 那些 每 天 都 要 “接待 ” 儿 万 甚至 儿 百 万 独立 连接 的 服 
务 器 来 说 ， 问 题 就 更 多 了 。 由 于 每 个 打开 的 TLS 连接 都 要 占用 内 存 ， 因 此 需要 一 套 
会 话 ID 缓存 和 清除 策略 ， 对 于 拥有 很 多 服务 器 而 且 为 获得 最 佳 性 能 必须 使 用 共享 
TLS 会 话 缓存 的 热门 站 点 而 言 ， 部 署 这 些 策略 绝 非 易 事 。 

当然 ， 这 些 问 题 并 非 无 解 ， 今 天 的 很 多 高 流量 站 点 都 在 成 功 地 使 用 会 话 标识 符 。 只 
不 过 对 于 多 服务 器 部 署 来 说 ， 为 确保 会 话 缓存 的 良性 循环 ， 必 须 对 会 话 标 识 符 进行 
周密 的 规划 和 系统 的 设计 。 





4.3.2 会 话 记 录 单 

为 了 解决 上 述 服务 器 端 部 署 TLS 会 话 缓存 的 问题 , “会 话 记录 单 ”(Session Ticket， 
RFC 5077) 机 制 出 台 了 ， 该 机 制 不 用 服务 器 保存 每 个 客户 端的 会 话 状 态 。 相 反 ， 如 
果 客 户 端 表明 其 支持 会 话 记 录 单 ， 则 服务 器 可 以 在 完整 TLS 担 手 的 最 后 一 次 交换 中 
添加 一 条 “新 会 话 记 录 单 ”(New Session Ticket) 记录 ， 包 含 只 有 服务 器 知道 的 安 
全 密 钥 加 密 过 的 所 有 会 话 数据 。 


然后 ， 客 户 端 将 这 个 会 话 记录 单 保存 起 来 ， 在 后 续 会 话 的 clientHello 消息 中 ， 可 
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以 将 其 包含 在 sessionTicket 扩展 中 。 这 样 ， 所 有 会 话 数据 只 保存 在 客户 端 ， 而 由 于 
数据 被 加 密 过 ， 且 密 钥 只 有 服务 器 知道 ， 因 此 仍然 是 安全 的 。 


我 们 这 里 所 说 的 会 话 标 识 符 和 会 话 记 录 单 机 制 ， 也 经 常 被 人 称 为 “会 话 缓存 ”或 “无 
状态 恢复 ”机 制 。 无 状态 恢复 机 制 的 优点 主要 是 消除 了 服务 器 端的 缓存 负担 ， 通 过 要 
求 客户 端 在 与 服务 器 建立 新 连接 时 提供 会 话 记录 单 简 化 了 部 署 ( 除 非 记录 单 过 期 )。 




















于 和 

es. 实践 中 ， 在 一 组 负载 均衡 服务 器 上 部 署 会 话 记录 单 仍 然 要 求 周密 规划 和 系 

4 4 ， 统 设计 。 比 如 ， 所 有 服务 器 一 开始 都 拥有 相同 的 会 话 密 钥 ， 然 后 再 通过 另 
必 ， 外 的 机 制定 期 在 所 有 服务 器 端 轮换 共享 的 密 铀 。 


ES 




















4.4 ”信任 链 与 证 书 颁发 机 构 


身份 验证 是 建立 每 个 TLS 连接 必 不 可 少 的 部 分 。 毕 竞 ， 加 密 信 道 两 端 可 以 是 任何 机 
器 ， 包 括 攻击 者 的 机 器 。 为 此 ， 必 须 确保 我 们 与 之 交谈 的 计算 机 是 可 信任 的 ， 否 则 
之 前 的 工作 都 是 徒劳 。 为 理解 如 何 验证 通信 两 端的 身份 ， 下 面 我 们 以 张 三 和 李 四 之 
间 的 验证 为 例 简单 说 明 一 下 : 


。 张 三 和 李 四 分 别 生成 自己 的 公 钥 和 私 钥 ， 

。 张 三 和 李 四 分 别 隐藏 自己 的 私 钥 ， 

。 张 三 向 李 四 公开 自己 的 公 钥 ， 李 四 也 向 张 三 公 开 自己 的 公 钥 ; 
。 张 三 向 李 四 发 送 一 条 新 消息 ， 并 用 自己 的 私 钥 签 名 ， 

。 李 四 使 用 张 三 的 公 钥 验证 收 到 的 消息 签名 。 


信任 是 上 述 交 流 的 关键 。 公 钥 加 密 可 以 让 我 们 使 用 发 送 端 的 公 钥 验证 消息 是 否 使 用 
了 正确 的 私 钥 签名 ， 但 认可 发 送 端 仍然 是 基于 信任 。 在 上 述 交 流 中 ， 张 三 和 李 四 可 
以 当面 交换 自己 的 公 钥 ， 因 为 他 们 互相 认识 ， 能 够 保证 不 被 别人 冒名 顶替 。 可 以 说 ， 
他 们 已 经 通过 之 前 安全 (物理 ) 的 握手 确认 了 对 方 。 


接 下 来 ， 张 三 收 到 王 五 发 来 的 一 条 消息 。 张 三 从 未 见 过 王 五 ， 但 王 五 自称 是 李 四 的 
朋友 。 事 实 上 ， 为 了 证 明 自 己 是 李 四 的 朋友 ， 王 五 还 请 李 四 用 李 四 的 私 钥 签 署 了 自 
己 的 公 钥 ， 并 在 消息 中 附 上 了 签名 (图 4-4)。 此 时 ， 张 三 首先 检查 王 五 公 钥 中 李 四 
的 签名 。 他 知道 李 四 的 公 钥 ， 因 而 可 以 验证 李 四 确 实 签署 了 王 五 的 公 钥 。 由 于 他 信 
任 李 四 对 王 五 的 签名 ， 所 以 就 接受 了 王 五 的 消息 ， 并 对 消息 进行 完整 性 检查 ， 以 确 
保 消息 确实 来 自 王 五 。 


刚才 这 个 过 程 建 立 了 一 个 信任 链 : 张 三 信 任 李 四 ， 李 四 信任 王 五 , 通过 信任 的 传递 ， 张 
三 信任 王 五 。 只 要 这 条 链 上 的 人 不 会 被 冒名 顶替 ， 我 们 就 可 以 继续 扩展 这 个 信任 网 络 。 
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图 4-4: 张 三 、 李 四 和 王 五 的 信任 链 
Web 以 及 训 览 器 中 的 身份 验证 与 上 述 过 程 相同 ， 这 就 意味 着 此 时 此 刻 你 应 该 问 自 
己 : 我 的 浏览 器 信任 谁 ?” 我 在 使 用 浏览 器 的 时 候 信 任 谁 ”》 这 个 问题 至 少 有 三 个 答案 。 
。 手工 指定 证 书 
所 有 浏览 器 和 操作 系统 都 提供 了 一 种 手工 导入 信任 证 书 的 机 制 。 至 于 如 何 获得 证 
书 和 验证 完整 性 则 完全 由 你 自己 来 定 。 





。 证 书 颁 发 机 构 
CA (Certificate Authority， 证 书 颁发 机 构 ) 是 被 证 书 接受 者 (拥有 者 ) 和 依赖 证 
书 的 一 方 共 同 信 任 的 第 三 方 。 


。 浏览 器 和 操作 系统 
每 个 操作 系统 和 大 多 数 浏览 器 都 会 内 置 一 个 知名 证 书 颁发 机 构 的 名 单 。 因 此 ， 你 
也 会 信任 操作 系统 及 浏览 器 提供 商 提供 和 维护 的 可 信任 机 构 。 


实践 中 ,保存 并 手工 验证 每 个 网 站 的 密 钥 是 不 可 行 的 (当然 ， 如 果 你 愿意 ， 也 可 
以 )。 现 实 中 最 常见 的 方案 就 是 让 证 书 颁 发 机 构 蔡 我 们 做 这 件 事 (图 4-5) : 浏览 器 
指定 可 信任 的 证 书 颁 发 机 构 ( 根 CA)， 然 后 验证 他 们 签署 的 每 个 站 点 的 责任 就 转移 
到 了 他 们 头 上 ， 他 们 会 审计 和 验证 这 些 站 点 的 证 书 没有 被 滥用 或 冒充 。 持 有 CA 证 
书 的 站 点 的 安全 性 如 果 遭 到 破坏 ， 那 撤销 该 证 书 也 是 证 书 颁发 机 构 的 责任 。 




















所 有 者 名 称 
所 有 者 公 钥 中 间 证 书 
颁发 者 (CA) 名 称 ”所 有 者 名 称 


颁发 者 签名 所 有 者 公 钠 根 证 书 磊 发 机 构 证 所 


上 
相 也 


验证 














图 4-5: 证 书 颁发 机 构 签署 数字 证 书 
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所 有 浏览 器 都 允许 用 户 检视 自己 安全 连接 的 信任 链 ， 常 见 的 访问 入 口 就 是 地 址 栏 头 
儿 上 的 锁 图 标 ， 点 击 即 可 查看 (图 4-6)。 








。 igvita.com 证 书 由 StartCom Class 1 Primary Intermediate Server 签发 。 

。 StartCom Class 1 Primary Intermediate Server 证 书 由 StartCom Certification Authority 
签发 。 

。 StartCom Certification Authority 被 认为 是 根 证 书 颁发 机 构 。 





声 IyaGrigorik -igvitacom x*x 


Cc GC @ https://www.igvita.com 让 | 三 





国 StartCom Certification Authority 
b 园 StartCom Class 1 Primary Intermediate Server CA 
Lb [3 www.igvita.com (ABjQuqt3nPv7ebEG) 





www.igvita.com (ABjQuqt3nPv7ebEG) 

lssued by: StartCom Class 1 Primary Intermediate Server CA 
Expires: Saturday, August 10, 2013 1:18:49 AM Pacific Daylight 
Time 


@ This certificate is valid 
pb Details 














4-6: igvita.com 的 证 书信 任 链 (谷歌 Chrome v25) 


整个 链条 的 “信任 依据 ”是 根 证 书 颁发 机 构 ， 在 这 里 就 是 StartCom Certification 
Authority。 每 个 浏览 器 都 会 内 置 一 个 可 信任 的 证 书 颁 发 机 构 ( 根 机 构 ) 的 名 单 ， 在 
此 浏览 器 相信 而 且 能 够 验证 StartCom 根 证 书 。 实 际 上 ， 通 过 浏览 器 到 浏览 器 开发 
商 ， 再 到 StartCom 证 书 颁发 机 构 的 信任 链 传递 ， 可 以 把 信任 扩展 至 目标 站 点 。 


所 有 操作 系统 和 浏览 器 在 默认 情况 下 都 会 提供 一 个 它们 信任 的 证 书 颁发 机 

4 4 、 构 名 单 。 如 果 你 想 进一步 了 解 ， 可 以 搜索 并 研究 研究 这 个 名 单 。 
司 ， 实践 中 ， 知 名 和 可 信任 的 证 书 颁发 机 构 有 好 儿 百 个 ， 而 这 也 是 系统 经 党 

到 责难 的 原因 。 想 象 一 下 ， 这 么 多 证 书 颁发 机 构 无 疑 会 构成 一 0 


击 面 ， 从 而 给 坏人 潜入 你 的 浏览 器 信任 链 提供 可 乘 之 机 。 

















4.5 证 书 撤销 


有 时 候 ， 出 于 种 种 原因 ， 证 书 颁发 者 需要 撤销 或 作废 证 书 ， 比 如 证 书 的 私 钥 不 再 安 
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人 全、 证书 颁发 机 构 本 身 被 冒名 顶替 ， 或 者 其 他 各 种 正常 的 原因 ， 像 以 旧 换 新 或 所 属 
关系 更 替 等 。 为 此 ， 证 书本 身 会 包含 如 何 检测 甚 是否 过 期 的 指令 (图 4-7) 。 为 确保 
信任 链 不 被 破坏 ,通信 的 任何 一 端 都 可 以 根据 嵌入 的 指令 和 签名 检查 链条 中 每 个 证 
书 的 状态 。 








加 ya crigorik -igvitacom x 


和 GC https://www.igvita.com yr| 三 








国 5StartCom Certification Authority 
。. 园 StartCom Class 1 Primary Intermediate Server CA 


b [Ly www.igvita.com (ABjQuqt3nPv7ebEG) 





CRL Distribution Points ( 2.5.29.31 ) 


Critical NO 
CRL URI http://crl.startssl.com/crtl-crl.crl 


Certificate Authority Information Access 
(1.3.6.1.5.5.7.1.1) 


Critical NO 
Method #1 Online Certificate Status Protocol 
ocsp (1.3.6.1.5.5.7.48.1 ) 


URI http://ocsp.startssl.com/subjclassl/server/ca 




















4-7: igvita.com 证 书 中 的 CRL 和 OCSP 指令 (谷歌 Chrome v25) 


4.5.1 ”证 书 撤销 名 单 (CRL) 


CRL (Certificate Revocation List， 证 书 撤销 名 单 ) 是 RFC 5280 规定 的 一 种 检查 所 
有 证 书 状态 的 简单 机 制 ， 每 个 证 书 颁发 机 构 维 护 并 定期 发 布 已 撤销 证 书 的 序列 号 名 
单 。 这 样 ， 任 何 想 验 证 证 书 的 人 都 可 以 下 载 撤销 名 单 ， 检 查 相 应 证 书 是 否 榜 上 有 名 。 
如 果 有 ， 说 明证 书 已 经 被 撤销 了 。 


CRL 文件 本 身 可 以 定期 发 布 、 每 次 更 新 时 发 布 ， 或 通过 HTTP 或 其 他 文件 传输 协议 
来 提供 访问 。 这 个 名 单 同 样 由 证 书 颁发 机 构 签名 ,通常 允许 被 缓存 一 定时 间 。 实 践 
中 ， 这 种 机 制 效 果 很 好 ， 但 也 存在 一 些 问 题 : 


。 CRL 名 单 会 随 着 要 撤销 的 证 书 增多 而 变 长 ， 每 个 客户 端 都 必须 取得 包含 所 有 序列 
号 的 完整 名 单 ; 

。 没有 办 法 立即 更 新 刚刚 被 撤销 的 证 书 序列 号 ， 比 如 客户 端 先 缓存 了 CRL， 之 后 茶 
证 书 被 撤销 ， 那 到 缓存 过 期 之 前 ， 该 证 书 将 一 直 被 视 为 有 效 。 
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4.5.2 在线 证 书 状态 协议 (OCSP) 

为 解决 CRL 机 制 的 上 述 问 题 ，REFC 2560 定义 了 OCSP (Online Certificate Status 
Protocol， 在 线 证 书 状 态 协议 ) ， 提 供 了 一 种 实时 检查 证 书 状态 的 机 制 。 与 CRL 包含 
被 撤销 证 书 的 序列 号 不 同 ，OCSP 支持 验证 端 直接 查询 证 书 数据 库 中 的 序列 号 ， 从 
而 验证 证 书 链 是 否 有 效 。 总 之 ，OCSP 占用 带宽 更 少 ， 支 持 实时 验证 。 








然而 ， 没 有 什么 机 制 是 完美 无 缺 的 ! 实时 OCSP 查询 也 带 了 一 些 问 题 : 





。 证 书 颁发 机 构 必 须 处 理 实时 查询 ， 

。 证 书 颁发 机 构 必 须 确保 随时 随地 可 以 访问 ，; 

。 客户 端 在 进一步 协商 之 前 阻塞 OCSP 请 求 ; 

。 由 于 证 书 颁发 机 构 知 道 客 户 端 要 访问 哪个 站 点 ， 因 此 实时 OCSP 请 求 可 能 会 泄露 
客户 端的 隐私 。 


实践 中 ，CRL 和 OCSP 机 制 是 互补 存在 的 ， 大 多 数 证 书 既 提供 指令 也 支持 

心 4 、 碍 询 。 

久 ' 更 重要 的 倒是 客户 端的 支持 和 行为 。 有 的 浏览 器 会 分 发 自己 的 CRL 名 单 ， 
有 的 浏览 器 从 证 书 颁发 机 构 取得 并 缓存 CRL 文件 。 类 似 地 ， 有 的 浏览 器 会 
进行 实时 OCSP 检查 ， 但 在 OCSP 请 求 失败 的 情况 下 行为 又 会 有 所 不 同 。 要 
了 解 具 体 的 情况 ， 可 以 检查 浏览 器 和 操作 系统 的 证 书 撤销 网 络 设置 。 














4.6 TLS 记 录 协 议 

与 位 于 其 下 的 全 或 TCP 层 没 有 什么 不 同 ，TLS 会 话 中 交换 的 所 有 数据 同样 使 用 规 
格 明 确 的 协议 进行 分 帧 (图 4-8)。TLS 记录 协议 负责 识别 不 同 的 消息 类 型 (握手 、 
歼 告 或 数据 ， 通 过 “内 容 类 型 ”字段 )， 以 及 每 条 消息 的 安全 和 完整 性 验证 。 











填充 〈 仅 适用 于 块 加 密 ) 














4-8: TLS 记录 结构 


交付 应 用 数据 的 典型 流程 如 下 。 
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邮 


。 记录 协议 接收 应 用 数据 。 

。 接收 到 的 数据 被 切 分 为 块 : 最 大 为 每 条 记录 2” 字 节 ， 即 16 KB 。 
。 压缩 应 用 数据 (可 选 )。 

。 添加 MAC (Message Authentication Code) 或 HMAC。 

。 使 用 商定 的 加 密 套 件 加 密 数 据 。 


以 上 几 步 完成 后 ， 加 密 数 据 就 会 被 交 给 TCP 层 传输 。 接 收 端 的 流程 相同 ， 顺 序 相 
反 : 使 用 商定 的 加 密 套 件 解 密 数 据 、 验 证 MAC、 提 取 并 把 数据 转交 给 上 层 的 应 用 。 
同样 ， 值 得 庆幸 的 是 以 上 过 程 都 由 TLS 层 帮 我 们 处 理 ， 而 且 对 大 多 数 应 用 都 是 完 
透明 的 。 不 过 ， 记 录 协 议 也 带 来 了 一 些 重 要 的 限制 ,务必 要 注意 : 








。 TLS 记录 最 大 为 16 KB ; 

。 每 条 记录 包含 5 字 节 的 首部 .MAC (在 SSL 3.0.TLS 1.0.TLS 1.1 中 最 多 20 字 节 ， 
在 TLS 1.2 中 最 多 32 字 节 )， 如 果 使 用 块 加 密 则 还 有 填充 ， 

。 必须 接收 到 整 条 记录 才能 开始 解密 和 验证 。 


有 可 能 的 话 ， 应 该 自主 选择 记录 大 小 ， 这 也 是 一 项 重要 的 优化 。 小 记录 会 因 记录 分 
帧 而 招致 较 大 开销 ， 大 记录 在 被 TLS 层 处 理 并 交付 应 用 之 前 ， 必 须 通 过 TCP 传输 
和 重新 组 装 。 


4.7 ”针对 TLS 的 优化 建议 


鉴于 网 络 协 议 的 分 层 架构 ， 在 TLS 之 上 运行 应 用 与 直接 通过 TCP 通信 没有 什么 不 
同 。 正 因为 如 此 ， 只 需要 对 应 用 进行 很 少 改动 甚至 不 用 改动 就 可 以 让 它 基 于 TLS 通 
信 。 当 然 ， 前 提 是 你 根据 2.5 节 “ 针 对 TCP 的 优化 建议 ”中 的 最 佳 实践 去 做 了 。 


不 过 ， 你 还 应 该 关心 TLS 部 署 运 维 的 一 些 方法 ， 比 如 服务 器 的 部 署 方式 和 地 理 位 
置 、TLS 记录 及 内 存 缓 冲 区 大 小 、 是 否 支 持 简 短 握手 ， 等 等 。 关 注 这 些 细 市 不 仅 能 
大 大 改善 用 户 体验 ， 还 能 帮 你 节省 运 维 成 本 。 


4.7.1 计算 成 本 

建立 和 维护 加 密 信道 给 两 端 带 来 了 额外 的 计算 复杂 度 。 特 别 地 ， 首 先 有 一 个 非 对 称 
( 公 钥 ) 加 密 ， 我 们 在 4.2 节 “TLS 握手 ”中 介绍 过 。 然 后 ， 在 握手 期 间 确定 共享 密 
钥 ， 作 为 对 后 续 TLS 记录 加 密 的 对 称 密 钥 。 


如 前 所 述 ， 公 钼 加 密 与 对 称 加 密 相 比 ， 需 要 更 大 的 计算 工作 量 。 因 此 ， 在 Web 发 展 
早期 ， 通 常 都 需要 专门 的 硬件 来 进行 “SSL 邱 载 ”。 好 在 现在 不 这 样 了 。 现 代 硬 件 突 
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飞 猛 进 的 发 展 为 减 小 这 种 损失 提供 了 强力 支持 ， 原 先 需要 专门 硬件 来 做 的 工作 ， 今 
接 通 过 CPU 就 能 完成 。Facebook、 谷 歌 等 大 公司 都 通过 TLS 向 数 百 万 用 户 提 
供 服务 ， 相 关 的 计算 工作 通过 软件 和 普通 的 计算 机 就 能 完成 。 


天 直 

















今年 (2010 年 ) 1 月 份 ，Gmail 切换 为 默认 使 用 HTTPS。 在 此 之 前 ， 它 只 是 
一 个 选项 ， 而 现在 所 有 用 户 都 在 使 用 HTTPS 在 浏览 器 与 谷歌 之 间 随 时 随地 
安全 地 收发 邮件 。 为 做 到 这 一 点 ， 我们 并 没有 部 署 额 外 的 机 器 ， 也 没有 专用 
硬件 。 在 我 们 的 前 端 机 器 上 ，SSL/TLS 计算 只 占 CPU 负载 的 不 到 1%， 每 个 
连接 只 占 不 到 10 KB 的 内 存 ， 以 及 不 到 2% 的 网 络 资源 。 很 多 人 认为 SSL/ 
TLS 占用 了 很 多 CPU 时间， 我 们 希望 上 述 几 个 数字 (首次 公开 ) 能 消除 人 
们 的 顾虑 。 


如 果 你 现在 不 想 往 下 再 看 了 ， 那 只 需要 记 住 一 件 事 : SSL/TLS 计算 已 经 不 是 
问题 了 。 
一 一 Adam Langley (谷歌 ) 


我 们 已 经 大 规模 部 署 了 TLS， 了 既 使 用 了 硬件 也 使 用 软件 负载 均衡 器 。 我 们 发 
现 当 前 基于 软件 的 TLS 实现 在 普通 CPU 上 已 经 运行 得 足够 快 ， 无 需 借助 专 
门 的 加 密 硬 件 就 能 够 处 理 大 量 的 HTTPS 请 求 。 我 们 使 用 运行 于 普通 硬件 上 
的 软件 提供 所 有 HTTPS 服务 。 





Doug Beaver (Facebook) 


尽管 如 此 ， 像 4.3 市 “TLS 会 话 恢复 ”中 介绍 的 技巧 对 优化 性 能 依旧 很 重要 ， 它 能 
帮 你 减少 计算 损失 和 TLS 握手 期 间 的 公 钥 加 密 延 迟 。CPU 也 不 应 该 处 理 本 不 该 处 理 
的 计算 。 





说 到 优化 CPU 周期 ， 一 定 别 忘 了 把 你 的 SSL 库 升 级 到 最 新 版 本 ， 在 此 基 
心 。 础 上 再 构建 Web 服务 器 和 代理 服务 器 ! 最 新 版 的 OpenSSL 在 性 能 方面 有 
全 了 明显 的 提升 ， 而 你 系统 中 默认 的 OpenSSL 库 很 有 可 能 已 经 过 时 了 。 








4.7.2 ”尽早 完成 〈 握 手 ) 
建立 连接 的 延迟 体现 在 每 个 TLS 连接 上 ， 包 括 新 连接 和 恢复 的 连接 ， 因 此 是 优化 的 
重点 。 我 们 知道 TCP 连接 首先 要 经 过 2.1 节 描 述 的 “三 次 握手 ”， 两 端 要 通过 
完整 的 往返 交换 SYN/SYN-ACK 分 组 。 其 次 ，4.2 市 介绍 的 “TLS 握手 ”在 完整 的 
情况 下 ， 需 要 两 次 额外 的 往返 ， 或 在 4.3 节 描 述 的 “TLS 会 话 恢 复 ” 的 情况 下 ， 需 
要 一 次 额外 的 往返 。 


最 差 的 情况 ， 在 实际 交换 应 用 数据 之 前 ， 建 立 TCP 和 TLS 连接 的 过 程 要 经 过 三 次 往 
返 ! 以 前 面 纽 约 的 客户 端 连接 伦敦 的 服务 器 为 例 ， 每 次 往返 耗 时 56 ms ( 见 表 1-1)， 

















次 
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那么 建立 完整 的 TCP 和 TLS 连接 需要 三 次 往返 即 168 ms， 而 恢复 TLS 会 话 需要 
112 ms。 当 然 ，56 ms 是 最 乐观 的 数字 ， 正 常情 况 下 延迟 越 长 ， 性 能 损失 越 严重 。 


因为 所 有 TLS 会 话 都 是 在 TCP 之 上 完成 的 ， 因 此 2.5 市 “针对 TCP 的 优化 建议 ” 
在 这 里 也 完全 适用 。 如 果 说 重用 TCP 连接 对 于 非 加 密 通 信和 是 一 个 重要 的 优化 手段 ， 
那么 这 个 手段 对 运行 在 TLS 上 的 应 用 同样 至 关 重要 。 换 名 话说 ， 只 要 能 省 掉 担 手 ， 
就 应 该 省 掉 。 如 果 必 须 担 手 ， 那 么 还 有 一 个 可 能 的 技巧 : 尽早 完成 。 


第 1 章 讨论 过 ， 我 们 不 能 指望 延迟 在 将 来 能 下 降 多 少 ， 因 为 光电 信号 的 传输 速度 已 
经 是 光速 的 一 个 非常 小 的 常数 因子 了 。 不 能 让 分 组 传播 更 快 ， 但 可 以 缩短 传播 距 
离 ! 尽早 完成 就 是 这 么 一 个 技巧 ， 即 通过 把 服务 器 放 到 离 用 户 更 近 的 地 方 (图 4-9)， 
让 客户 端 与 服务 器 之 间 往 返 延迟 最 少 。 























原始 服务 器 














4-9: 客户 端 连接 的 尽早 完成 


做 到 尽早 完成 的 最 简单 方式 ， 就 是 在 世界 各 地 的 服务 器 上 缓存 或 重复 部 署 数据 和 服 
务 ， 而 不 要 让 所 有 用 户 都 通过 跨 海 或 跨 大 陆 光 缆 连 接 到 一 个 中 心 原始 服务 器 。 当 然 ， 
这 正 是 CDN (Content Delivery Networks， 内 容 分 发 网 络 ) 服务 的 内 容 : 通过 使 用 
本 地 代理 服务 器 分 流 负载 等 手段 降低 延迟 。 


虽然 CDN 最 常用 于 在 全 球 优化 分 发 静态 资源 ， 但 其 优点 并 不 止 于 此 。 上 距离 客户 端 
更 近 的 服务 器 还 可 以 缩短 TLS 会 话 ， 因 为 TCP 和 TLS 握手 的 对 象 都 是 近 处 的 服务 
器 ， 所 以 建立 连接 的 总 延迟 就 会 显著 减少 。 相 应 地 ， 本 地 代理 服务 器 则 可 以 与 原始 
服务 器 建立 一 批 长 期 的 安全 连接 ， 全 权 代 理 请 求 与 响应 。 


简 言 之 ， 把 服务 器 放 到 接近 客户 端的 地 方 能 够 节约 TCP 和 TLS 握手 的 时 间 ! 大 多 数 
CDN 提供 商都 提供 这 种 服务 ， 当 然 如 果 你 愿意 也 可 以 以 最 小 的 成 本 部 署 自己 的 基础 
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设 


务 


施 : 在 全 球 几 大 数据 中 心 租 用 一 些 云 服 务 器 ， 然 后 在 每 台 服 务 器 上 都 运行 代理 ( 服 
器 ) 程序 ， 把 请 求 转发 到 你 的 原始 服务 器 ， 再 加 上 地 理 DNS 负载 均衡 系统 即 可 。 











origin fetch) 。 


缕 存 的 原始 获取 ”仍然 具有 性 能 优势 : 客户 端 连接 终止 于 附近 的 服务 器 ， 从 而 


速 响 应 。 


据 在 优化 的 CDN 骨干 网 中 寻 路 ， 从 而 进一步 减少 客户 编 与 服务 器 之 间 的 延迟 。 


不 缓存 的 原始 获取 


使 用 CDN 或 代理 服务 器 取得 资源 的 技术 ， 如 果 要 根据 用 户 定制 或 者 涉及 隐私 
数据 ， 则 不 能 做 到 全 球 缓 存 ， 这 种 情况 被 称 为 “不 缓存 的 原始 获取 ”(uncached 


虽然 只 有 把 数据 缓存 到 全 球 各 地 的 服务 器 上 CDN 才能 发 挥 最 大 的 效用 ， 但 “不 


显著 减少 握手 延迟 。 相 应 地 ，CDN 或 你 的 代理 服务 器 可 以 维护 一 个 “ 热 连接 池 ” 
(warm connection pool) ， 通 过 它 将 数据 转发 给 原始 服务 器 ， 同 时 做 到 对 客户 端 快 


事实 上 ， 作 为 附加 的 一 个 优化 层 ，CDN 提供 商 在 连接 两 端 都 会 使 用 令 近 服务 器 | 
客户 端 连接 终止 于 邻近 CDN 节点 ， 该 节点 将 请 求 转发 到 与 对 端 服务 器 邻近 的 CDN 
节点 ， 之 后 请 求 才 会 被 路 由 到 原始 服务 器 。CDN 网 络 中 多 出 来 这 一 跳 ， 可 以 让 数 
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.7.3 会 话 缓存 与 无 状态 恢复 


无 论 什么 情况 下 ， 在 接近 用 户 的 地 方 终止 连接 都 有 助 于 减少 延迟 ， 但 有 延迟 终归 快 不 
过 没有 延迟 。 局 用 TLS 会 话 缓存 和 无 状态 恢复 可 以 完全 消除 “回头 客 ” 的 往返 时 间 。 


SSL 2.0 引入 的 会 话 标识 符 机 制 是 TLS 会 话 缓存 的 基础 ， 目 前 已 经 得 到 大 多 数 客户 
端 和 浏览 器 的 广泛 支持 。 然 而 ， 如 果 你 在 自己 的 服务 器 上 配置 SSL/TLS， 千 万 不 能 
主观 认为 该 机 制 默认 是 开启 的 。 实 际 上 ， 在 大 多 数 服务 器 的 默认 配置 下 它 是 禁用 的 。 
为 此 ， 应 该 仔细 检查 和 验证 自己 的 配置 : 





支持 多 进程 或 工作 进程 的 服务 器 应 该 使 用 共享 的 会 话 缓存 ， 

共享 的 会 话 缓存 的 大 小 应 该 根据 流量 调整 ，; 

应 该 设置 会 话 超时 时 间 ， 

在 多 台 服 务 器 并 存 的 情况 下 ， 把 相同 的 客户 端 IP 或 相同 的 TLS 会 话 ID 路 由 到 同 
一 台 服 务 器 可 以 最 好 地 利用 会 话 缓 存 ; 

在 不 适宜 使 用 “单一 ”负载 均衡 策略 的 情况 下 , 应 该 为 多 台 服 务 器 配置 共享 缓存 ， 
以 便 最 好 地 利用 会 话 缓存 ; 

检查 和 监控 SSL/TLS 会 话 缓存 的 使 用 情况 ， 以 之 作为 性 能 调 优 的 依据 。 








此 外 ， 如 果 客 户 端 和 服务 器 都 支持 会 话 记 录 单 ， 则 所 有 会 话 数据 都 将 保存 在 客户 端 ， 
上 述 步 又 就 都 不 需要 了 (问题 一 下 子 就 简单 了 很 多 ) ! 不 过 ， 由 于 会 话 记录 单 还 是 
相对 新 的 TLS 扩展， 并非 所 有 客户 端 都 支持 它 。 实 践 中 ， 为 了 取得 最 优 结果 ， 应 该 
做 好 两 手 准 备 : 在 支持 的 客户 端 中 使 用 会 话 记录 单 ， 而 在 不 支持 的 客户 端 中 使 用 会 
话 标识 符 。 这 两 种 手段 不 会 相互 干扰 ， 而 是 会 很 好 地 协同 工作 。 








4.7.4 TLS 记 录 大 小 


所 有 通过 TLS 交付 的 应 用 数据 都 会 根据 记录 协议 传输 (图 4-8)。 每 条 记录 的 上 限 
为 16 KB ， 视 选择 的 加 密 方式 不 同 ， 每 条 记录 还 可 能 额外 带 有 20 到 40 字 节 的 首部 、 
MAC 及 可 选 的 填充 信息 。 如 果 记 录 可 以 封装 在 一 个 TCP 分 组 内 ， 则 还 会 给 它 增 加 
相应 的 IP 和 TCP 字段 ， 即 20 字 节 的 IP 首部 和 20 字 节 的 TCP 首部 (无 选项 )。 结 
果 ， 每 条 记录 的 大 小 就 变 成 了 60 到 100 字 节 。 由 于 MTU 通常 为 1500 字 节 ， 因 此 
分 组 占 比 最 小 的 情况 下 只 相当 于 帧 大 小 的 6%。 


记录 越 小 ， 分 帧 浪费 越 大 。 但 简单 地 把 记录 增 大 到 上 限 (60 KB) 也 不 一 定好 ! 如 
果 记 录 要 分 成 多 个 TCP 分 组 ， 那 TLS 层 必须 等 到 所 有 TCP 分 组 都 到 达 之 后 才能 解 
密 数 据 (图 4-10)。 只 要 有 TCP 分 组 因 拥 塞 控 制 而 丢失 、 失 序 或 被 节 疲 ， 那 就 必须 
将 相应 TLS 记录 的 分 段 缓存 起 来 ， 从 而 导致 额外 的 延迟 。 实 践 中 ， 这 种 延迟 会 造成 
浏览 器 性 能 显著 下 降 ， 因 为 浏览 器 倾向 于 逐 字 节 地 读 取 数 据 。 

















v [8 Reassembled TCP Segments (11221 bytes): #169(1460), #170(1460), #172(1460), #174(1460), 
#175(1460), #177(1460), #179(1460), #180(1001)] 
Frame: 169, payload: 0-1459 (1469 bytes)] 
[Frame: 170，payLoad: 1460-2919 (1469 bytes)] 
Frame: 172, payload: 2920-4379 (1460 bytes)] 
[Frame: 174, payload: 4380-5839 (1460 bytes)] 
[Frame: 175, payload: 5840-7299 (1460 bytes)] 
Frame: 177, payload: 7300-8759 (1460 bytes)] 
Frame: 179, payload: 8760-19219 (1460 bytes)] 
Frame: 189, payload: 10220-11220 (1001 bytes)] 
Segment count: 8] 
Reassembled TCP length: 11221] 
v Secure Sockets Layer 
YY TLSv1 Record Layer: Application Data Protocol: http 
Content Type: Application Data (23) 
Version: TLS 1.0 (0x0301) 
Length: 11216 
Encrypted Application Data: Q7ed92e420530da2e2755a5b5372ef32b53e0d4e7c20c3d8,.. 






































图 4-10， WireShark 的 截图 ， 其 中 11 211 字 节 的 TLS 记录 被 分 成 了 8 个 TCP 段 

小 记录 会 造成 浪费 ， 大 记录 会 导致 延迟 。 因 此 ， 记 录 到 底 多 大 合适 没有 唯一 “ 正 
确 ” 的 答案 。 不 过 对 于 在 浏览 器 中 运行 的 Web 应 用 来 说 ， 倒 是 有 一 个 值得 推荐 的 做 
法 : 每 个 TCP 分 组 恰好 封装 一 个 TLS 记录 ， 而 TLS 记录 大 小 恰好 占 满 TCP 分 配 的 
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MSS (Maximum Segment Size， 最 大 段 大 小 ) 。 换 名 话说 ， 一 方面 不 要 让 TLS 记录 
分 成 多 个 TCP 分 组 ， 另 一 方面 又 要 尽量 在 一 条 记录 中 多 发 送 数据 。 以 下 数据 可 作为 
确定 最 优 TLS 记录 大 小 的 参考 : 


。 IPv4 帧 需要 20 字 节 ，IPv6 需要 40 字 节 ， 
。 TCP 帧 需要 20 字 节 ， 
。 TCP 选项 需要 40 字 节 (时 间 戳 、SACK 等 ) 。 


假设 常见 的 MTU 为 1500 字 节 ， 则 TLS 记录 大 小 在 IPv4 下 是 1420 字 节 ， 在 IPv6 
下 是 1400 字 节 。 为 确保 向 前 兼容 ， 建 议 使 用 IPv6 下 的 大 小 : 1400 字 节 。 当 然 ， 如 
果 MTU 更 小 ， 这 个 值 也 要 相应 调 小 。 


可 惜 的 是 ， 我 们 不 能 在 应 用 层 控制 TLS 记录 大 小 。TLS 记录 大 小 通常 是 一 个 设置 ， 
其 至 是 TLS 服务 器 上 的 编译 时 和 常量 或 标志 。 要 了 解 具体 如 何 设 置 这 个 值 ， 请 参考 服 
务 器 文档 。 


二 所 
， 














如 果 服 务 器 要 处 理 大 量 TLS 连接 ， 那 么 关键 的 优化 是 把 每 个 连接 占用 的 内 
人 4， 存量 控制 在 最 小 。 默 认 情况 下 ，OpenSSL 等 常用 的 库 会 给 每 个 连接 分 配 50 
发 ，KB 空间 ， 但 正 像 设 置 记录 大 小 一 样 ， 有 必要 查 一 查 文档 或 者 源 代码 ， 然 
后 再 决定 如 何 调整 这 个 值 。 谷 歌 的 服务 器 把 OpenSSL 缓冲 区 的 大 小 减少 到 
了 大 约 5 KB。 














4.7.5 _ TLS 压缩 

TLS 还 有 一 个 内 置 的 小 功能 ， 就 是 支持 对 记录 协议 传输 的 数据 进行 无 损 压 缩 。 压 缩 
算法 在 TLS 握手 期 间 商 定 ， 压 缩 操作 在 对 记录 加 密 之 前 执行 。 然 而 ， 出 于 如 下 原 
因 ， 实 践 中 往往 需要 禁用 服务 器 上 的 TLS 压缩 功能 : 


。 2012 年 公布 的 “CRIME” 攻 击 会 利用 TLS 压缩 恢复 加 密 认 证 cookie， 让 攻击 者 
实施 会 话 动 持 ; 
。 传输 级 的 TLS 压缩 不 关心 内 容 , 可 能 会 再 次 压缩 已 经 压缩 过 的 数据 (图 像 、 视 频 ， 


等 等 ) 
可 可 6 














双重 压缩 会 浪费 服务 器 和 客户 端的 CPU 时 间 ， 而 且 暴 露 的 安全 漏洞 也 很 严重 ， 因 此 
请 禁用 TLS 压缩 。 实 践 中 ， 大 多 数 浏 览 器 会 禁用 TLS 压缩 ， 但 即便 如 此 你 也 应 该 
在 服务 器 的 配置 中 明确 禁用 它 ， 以 保护 用 户 的 利益 。 








泣 包 


虽然 不 能 使 用 TLS 压缩 ， 但 应 该 使 用 服务 器 的 Gzip 设置 压缩 所 有 文本 资 
心 。 源 ， 同 时 对 图 像 、 视 频 、 音 频 等 媒体 采用 最 合适 的 压缩 格式 。 


0, 
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4.7.6 ”证书 链 的 长 度 

验证 信任 链 需 要 浏览 器 遍历 链条 中 的 每 个 布点 ， 从 站 点 证 书 开始 递归 验证 父 证 书 ， 
直至 信任 的 根 证 书 。 因 此 ， 优 化 的 首要 工作 就 是 检查 服务 器 在 握手 时 没有 忘记 包含 
所 有 中 间 证 书 。 如 果 忘 记 了 包含 中 间 证 书 ， 虽 然 很 多 浏览 器 可 以 正常 工作 ， 但 它们 
会 暂停 验证 并 自己 获取 中 间 证 书 ， 验 证 之 后 再 继续 。 此 时 很 可 能 需要 进行 新 DNS 查 
找 、 建 立 TCP 连接 、 发 送 HTTP GET 请 求 ， 导 致 担 手 多 花 几 百 ms 时 间 。 


5 





浏览 器 怎么 知道 到 哪里 去 找 证 书 呢 ? 子 证 书 中 通常 包含 父 证 书 的 URL。 





4 
te 
、 





8 
人， 


另 一 方面 ， 还 要 确保 信任 链 中 不 包含 不 必要 的 证 书 ! 或 更 一 般 化 地 讲 ， 应 该 确保 证 
书 链 的 长 度 最 小 。 我 们 在 4.2 节 “TLS 握手 ”中 介绍 过 ， 服 务 器 证 书 是 在 握手 期 间 
发 送 的 ， 而 发 送 证 书 使 用 的 很 可 能 是 一 个 处 于 2.2.2 市 “ 慢 启 动 ” 算 法 初始 阶段 的 
新 TCP 连接 。 如 果 证 书 链 长 度 超过 了 TCP 的 初始 拥塞 窗口 (图 4-11)， 那 我 们 无 意 
间 就 会 让 握手 多 了 一 次 往返 : 证 书 长 度 超过 拥塞 窗口 ， 从 而 导致 服务 器 停 下 来 等 待 
客户 端的 ACK 消息 。 











bP [4 Reassembled TCP Segments (5341 bytes): #98(1402), #99(1460), #101(1176), #102(1303)] 
wd 





SF 





Content Type: Handshake (22) 
Version: TLS 1.1 (0x0302) 
Length: 5327 

vy 


Handshake Type: Certificate (11) 
Length: 5323 
Certificates Length: 5320 

> 











4-11: WireShark 的 截图 显示 的 5323 字 节 的 TLS 证 书 链 


图 4-11 所 示 的 证 书 链 超 过 了 5 KB， 也 超过 了 大 多 数 旧 版 本 浏览 器 的 初始 拥塞 窗口 
大 小 ， 因 此 会 在 握手 期 间 增加 一 次 额外 的 往返。 对 此 ， 可 以 通过 增 大 拥塞 窗口 来 解 
决 ， 参 见 2.2.2 节 最 后 的 “ 增 大 TCP 的 初始 拥塞 窗口 ”部 分 。 此 外 ， 就 是 要 看 一 看 
能 否 减少 要 发 送 的 证 书 大 小 了 。 


。 尽量 减少 中 间 证 书 颁发 机 构 的 数量 。 理 想 情况 下 ， 发 送 的 证 书 链 应 该 只 包含 两 个 
证 书 : 站 点 证 书 和 中 间 证 书 颁 发 机 构 的 证 书 。 把 这 一 条 作为 选择 证 书 颁发 机 构 的 
标准 。 第 三 个 证 书 ， 也 就 是 根 证书 颁 发 机 构 的 证 书 ， 已 经 包含 在 浏览 器 内 置 的 信 
任 名 单 中 了 ， 不 用 发 送 。 

。 很 多 站 点 会 在 证 书 链 中 包含 根 证 书 颁 发 机 构 的 证 书 ， 这 是 完全 没有 必要 的 。 如 果 浏 
览 器 的 信任 名 单 中 没有 该 根 证 书 , 那 说 明 它 是 不 被 信任 的 , 即便 发 送 它 也 无 济 于 事 。 
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。 理想 的 证 书 链 应 该 在 2 KB 或 3 KB 左右 ,同时 还 能 给 浏览 器 提供 所 有 必要 的 信息 ， 
避免 不 必要 的 往返 或 者 对 证 书本 身 额 外 的 请 求 。 优 化 TLS 握手 可 以 消除 关键 的 性 
能 瓶颈， 因为 每 个 新 TLS 连接 都 要 经 历 同 样 的 延迟 。 











4.7.7 OCSP 封 套 

每 个 新 TLS 连接 都 要 求 浏览 器 验证 发 送 过 来 的 证 书 链 的 签名 。 然 而 ， 不 要 忘 了 还 
有 一 步 : 浏览 器 也 需要 验证 证 书 没有 被 撤销 。 为 此 ， 浏 览 器 可 能 会 定期 下 载 并 缓存 
4.5.1 市 提 到 的 证 书 颁发 机 构 发 布 的 “证 书 撤销 名 单 (CRL)”， 而 且 还 可 能 需要 分 派 
发 送 一 个 4.5.2 亨 提 到 的 “在 线 证 书 状态 协议 (OCSP)” 请 求 ， 以 便 实时 验证 。 遗 
憾 的 是 ， 浏 览 器 在 这 时 候 的 行为 差别 很 大 。 


。 某 些 浏 览 器 会 使 用 自己 的 更 新 机 制 推送 更 新 的 CRL 名 单 ， 而 不 会 按 需 发 送 请 求 。 

。 某 些 浏览 器 可 能 只 会 针对 扩展 验证 证 书 (EV 证 书 ) 进行 实时 OCSP 和 CRL 检查 。 

。 某 些 浏览 器 可 能 会 在 上 述 任何 一 种 方式 下 阻塞 TLS 握手 ， 有 些 则 不 会 ， 具体 情况 
取决 于 开发 商 、 平 台 和 浏览 器 版 本 。 


这 里 的 情况 很 复杂 ， 也 没有 最 好 的 解决 方案 。 不 过 ， 在 某 些 浏 览 嚣 中 还 是 可 以 采用 
一 个 叫做 OCSP 封套 (OCSP stapling) 的 优化 措施 : 服务 器 可 以 在 证 书 链 中 包含 
(封套 ) 证 书 颁发 机 构 的 OCSP 响应 ,让 浏览 器 跳 过 在 线 查 询 。 把 查询 OCSP 操作 
转移 到 服务 器 可 以 让 服务 器 缓存 签名 的 OCSP 响应 ， 从 而 节省 很 多 客户 端的 请 求 。 
与 此 同时 ， 还 要 注意 一 些 情况 。 


。 OCSP 响应 从 400 字 节 到 4000 字 节 不 等 。 把 这 么 大 的 响应 封套 在 证 书 链 里 照样 
会 造成 TCP 拥塞 窗口 溢出 ， 因 此 要 关 广 整体 大 小 。 

。 只 能 包含 一 个 OCSP 响应 ， 即 在 没有 缓存 的 情况 下 ,浏览 器 对 其 他 中 间 证 书 可 能 
仍然 需要 发 送 OCSP 请 求 。 


最 后 ， 要 启用 OCSP 封套 ， 还 需要 服务 器 支持 才 行 。 好 在 ，NginX、Apache 和 了 IIS 
等 服务 器 都 可 以 通过 配置 支持 OCSP 封套 。 对 于 其 他 服务 器 ， 请 参考 文档 中 的 说 明 。 



































4.7.8 HTTP 严格 传输 安全 (HSTS ) 

HTTP 严格 传输 安全 (HSTS ，Strict Transport Security) 是 一 种 安全 策略 机 制 ， 它 能 让 
服务 器 通过 简单 的 HITP 首部 (如 Strict-Transport-Security: max-age=31536000) 
对 适用 的 浏览 器 声明 访问 规则 。 具 体 来 讲 ， 它 可 以 让 用 户 代 理 遵从 如 下 规则 : 

。 所 有 对 原始 服务 器 的 请 求 都 通过 HTTPS 发 送 ， 

。 所 有 不 安全 的 链接 和 客户 端 请 求 在 发 送 之 前 都 应 该 在 客户 端 自动 转换 为 HTTPS 
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。 万 一 证 书 有 错误 ， 则 显示 错误 销 息 ， 用 户 不 能 回避 警告 ; 

。 max-age 以 秒 为 单位 指定 HSTS 规则 集 的 生存 时 间 (例如 ，max-age=31536000 等 于 
缓存 365 天 ) ; 

。 用 户 代 理 可 以 根据 指令 在 指定 的 证 书 链 中 记 住 (“ 印 下 ”) 某 主机 的 指纹 ， 以 便 将 
来 访问 时 使 用 ， 从 而 有 效 限制 证 书 颁 发 机 构 在 特定 时 间 (由 max-age 指定 ) 内 可 
颁发 证 书 的 范围 。( 这 一 项 是 可 选 的 。) 


事实 上 ，HSTS 会 把 原始 服务 器 转换 为 只 处 理 HTTPS 的 目标 服务 器 ， 从 而 确保 应 用 
` 会 因 各 种 主动 或 被 动 攻击 给 用 户 造 成 损失 。 从 性 能 角度 说 ，HSTS 通过 把 责任 转 
移 到 客户 端 ， 让 客户 端 自动 把 所 有 链接 重 写 为 HTTPS， 消 除了 从 HTTP 到 HTTPS 
的 重 定 向 损失 。 














。 和 Android 平台 的 Chrome 和 Firefox。 要 了 解 最 新 的 支持 情况 ， 请 访问 : 


http://caniuse.com/stricttransportsecurity 。 


:| 
惠 、 到 2013 年 初 ， 支 持 HSTS 的 浏览 器 有 Firefox 4+、Chrome 4+、Opera 12+ 
AN 
~ 





4.8 性 能 检查 清 

作为 应 用 开发 人 员 ， 事 实 上 你 接触 不 到 TLS 的 这 些 复杂 性 。 只 要 别 把 页 面 中 的 
HTTP 和 HTTPS 内 容 混 为 一 谈 ， 那 你 的 应 用 就 可 以 在 这 两 种 情况 下 都 顺畅 运行 。 然 
而 ， 应 用 的 整体 性 能 却 会 受到 服务 器 底层 配置 的 影响 。 


好 在 ， 只 要 想到 优化 ， 任 何 时 候 都 不 算 晚 。 而 且 一 旦 优化 到 位 ， 所 有 与 服务 器 的 新 
连接 都 将 受益 无 穷 ! 下 面 是 一 个 简单 的 检查 清单 : 


。 要 最 大 限制 提升 TCP 性 能 ， 请 参考 2.5 市 “针对 TCP 的 优化 建议 ”; 
。 把 TLS 库 升级 到 最 新 版 本 ， 在 此 基础 上 构建 (或 重新 构建 ) 服务 器 ， 
。 启用 并 配置 会 话 缓 存 和 无 状态 恢复 ， 

。 监控 会 话 缓 存 的 使 用 情况 并 作出 相应 调整 ， 

。 在 接近 用 户 的 地 方 完 成 TLS 会 话 ， 尽 量 减少 往返 延迟 ， 

。 配置 TLS 记录 大 小 ， 使 其 恰好 能 封装 在 一 个 TCP 段 内 ， 

。 确保 证 书 链 不 会 超过 拥塞 窗口 的 大 小 ，; 

。 从 信任 链 中 去 掉 不 必要 的 证 书 ， 减 少 链条 层次 ; 

。 禁用 服务 器 的 TLS 压缩 功能 ; 

。 启用 服务 器 对 SNI 的 支持 ， 

。 启用 服务 器 的 OCSP 封套 功能 ; 

。 追加 HTTP 严格 传输 安全 首部 。 
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4.9 测试 与 验证 


最 后 


， 要 验证 和 测试 你 的 配置 ， 可 以 使 用 Qualys SSL Server Test (https://www. 


ssllabs.com/ssltest/) 等 在 线 服务 来 扫描 你 的 服务 器 ， 以 发 现 常见 的 配置 和 安全 漏洞 。 
此 外 ， 最 好 熟练 掌握 openssl 命令 行 工 具 ， 通 过 它 来 检查 整个 握手 和 本 地 服务 器 配 
置 情 况 : 




















$> openssL s_client -state -CAfile startssl.ca.crt -connect igvita.com:443 


CONNECTED(00000003) 
SSL_connect:before/connect initialization 
SSL_connect:SSLv2/v3 write client hello A 
SSL_connect:SSLv3 read server hello A 
depth=2 /C=IL/0=StartCom Ltd./OU=Secure Digital Certificate Signing 
/CN=StartCom Certification Authority 
verify return:1 
depth=1 /C=IL/0=StartCom Ltd./OU=Secure Digital Certificate Signing 
/CN=StartCom Class 1 Primary Intermediate Server CA 
verify return:1 
depth=0 /description=ABjQuqt3nPv7ebEG/C=US 
/CN=www.igvita.com/emailAddress=ilya@igvita.com 
verify return:1 
SSL_connect:SSLv3 read server certificate A 
SSL_connect:SSLv3 read server done A@ 
SSL_connect:SSLv3 write client key exchange A 
SSL_connect:SSLv3 write change cipher spec A 
SSL_connect:SSLv3 write finished A 
SSL_connect:SSLv3 flush data 
SSL_connect:SSLv3 read finished A 
Certificate chain @ 
0 s:/description=ABjQuqt3nPv7ebEG/C=US 
/CN=www. igvita.com/emailAddress=ilya@igvita.com 
i:/C=IL/0=StartCom Ltd./OU=Secure Digital Certificate Signing 
/CN=StartCom Class 1 Primary Intermediate Server CA 
1 s:/C=IL/0=StartCom Ltd./OU=Secure Digital Certificate Signing 
/CN=StartCom Class 1 Primary Intermediate Server CA 
i:/C=IL/0=StartCom Ltd./OU=Secure Digital Certificate Signing 
/CN=StartCom Certification Authority 


Server certificate 


“ SNip. 3,. 


No client certificate CA names sent 


SSL handshake has read 3571 bytes and written 444 bytes © 
New, TLSv1/SSLv3, Cipher is RC4-SHA 

Server public key is 2048 bit 

Secure Renegotiation IS supported 

Compression: NONE 
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Expansion: NONE 
SSL-Session: 
Protocol : TLSv1 
Cipher : RC4-SHA 
Session-ID: 269349C84A4702EFA7 ... @ 
Session-ID-ctx: 
Master-Key: 1F5F5F33D50BE6228A ... 


Key-Arg : None 
Start Time: 1354037095 
Timeout : 300 (sec) 


Verify return code: 0 (ok) 


@ 客户 端 完成 对 接收 到 的 证 书 链 的 验证 
@ 接收 到 的 证 书 链 (2 个 证 书 ) 

@ 接收 到 证 书 链 的 大 小 

@ 对 有 状态 TLS 恢复 发 送 的 会 话 标识 符 


在 上 面 的 例子 中 ， 我 们 连接 到 igvita.com 默认 的 TLS 端口 (443) ， 并 进行 了 TLS 担 
手 。 因 为 s_cLient 假设 没有 根 证 书 ， 所 以 我 们 手工 把 路 径 指 定 为 StartSSL Certificate 
Authority 的 根 证 书 ， 这 一 点 很 重要 。 你 的 浏览 器 内 置 了 StartSSL 的 根 证书 ， 因 此 可 
以 验证 这 个 信任 链 ， 但 s_client 没有 依赖 于 此 。 如 有 果 在 这 里 忽略 根 证 书 ， 应 该 会 在 
日 志 中 看 到 验证 错误 。 


通过 检查 证 书 链 ， 我 们 发 现 服 务 器 发 送 了 两 个 证 书 ， 累 计 起 来 是 3571 字 节 ， 差 不 
多 相当 于 3~4 个 TCP 初始 拥塞 窗口 的 大 小 。 这 里 要 注意 不 能 超过 拥塞 窗口 大 小 ， 否 
则 惑 要 考虑 增 大 服务 器 上 cwnd 的 值 。 最 后 ， 我 们 可 以 看 到 协商 后 的 SSL 会 话 变量 : 
选择 的 协议 、 加 密 套 件 、 密 钥 等 。 还 可 以 看 到 服务 器 为 当前 会 话 发 送 的 会 话 标识 符 ， 
这 个 标识 符 在 将 来 恢复 时 会 用 到 。 
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无 线 网 络 概 多 





5.1 无 所 不 在 的 连接 


过 去 十 年 来 ， 最 具 颠 覆 性 的 技术 趋势 非 随时 随地 上 网 莫 属 ， 人 们 对 随时 随地 上 网 的 
需求 也 与 日 俱 增 。 无 论 是 查收 邮件 、 语 音 聊天 、 上 网 浏览 ， 还 是 其 他 需求 ， 总 之 人 
们 都 希望 随时 随地 访问 各 种 在 线 服务 ， 跑步 时 、 排 队 时 、 上 班 时 、 乘 地 铁 时 、 坐 飞 
机 时 …… 不 受 地 域 、 时 间 及 环境 的 限制 。 今 天 ， 为 满足 这 些 需求 ， 我 们 经 常 还 是 要 
提前 找 接 入 点 (比如 寻找 附近 的 Wi-Fi 热点 ) ， 但 攻 良 置疑， 未 来 的 愿景 一 定 是 随时 
随地 上 网 。 


无 线 网 络 是 这 股 趋 势 的 核心 所 在 。 宽 泛 地 说 ， 无 线 网 络 可 以 指 任何 不 通过 线 缆 连 接 
的 网 络 ， 只 有 不 通过 线 缆 才能 满足 移动 用 户 随 时 随地 上 网 的 需求 。 毫 不 奇怪 ， 面 对 
那么 多 的 使 用 场景 和 应 用 形式 ， 无 线 技术 自然 也 会 多 种 多 样 ， 而 且 各 有 各 的 特点 ， 
各 有 各 的 优势 。Wi-Fi、 蓝 牙 、ZigBee、NFC、WiMAX、LTE、HSPA、EVDO, 以 
及 早先 的 3G 标准 、 卫 星 服 务 等 ， 都 是 我 们 今天 司空 见 惯 的 无 线 网 络 技 术 。 


鉴于 无 线 网 络 技术 如 此 多 样 ， 党 统 地 概括 所 有 无 线 网 络 的 性 能 优化 手段 是 不 可 能 的 。 
然而 ， 好 在 大 多 数 无 线 技术 的 原理 都 是 相通 的 ， 各 种 技术 也 都 具有 类 似 的 权衡 因素 ， 
而 且 衡 量 性 能 的 指标 和 约束 条 件 也 具有 普遍 适用 性 。 只 要 我 们 把 影响 无 线性 能 的 基 
本 原理 搞 清 楚 ， 那 其 他 问题 自然 也 就 迎刃而解 了 。 


另外 ， 尽 管 通过 无 线 电 传播 数据 与 通过 有 线 传 输 数据 有 着 本 质 的 差别 ， 但 用 户 期 待 
的 结果 都 是 〈 或 者 说 应 该 是 ) 一 样 的， 一 样 的 性 能 ， 一 样 的 结果 。 从 长 远 来 看 ， 所 
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有 应 用 都 会 或 都 将 会 通过 无 线 网 络 交付 ， 只 不 过 某 些 应 用 通过 无 线 网 络 来 获取 的 步 
伐 会 走 得 更 快 一 些 。 世 上 根本 不 存在 什么 有 线 应 用 ， 交 付 方式 是 有 线 还 是 无 线 ， 用 
户 才 不 关心 呢 。 

无 论 连 接 方式 是 有 线 还 是 无 线 ， 应 用 都 应 该 一 如 既往 地 正常 运行 。 从 用 户 角 度 说 ， 
他 不 用 考虑 底层 技术 ， 但 作为 开发 人 员 ， 则 必须 在 设计 阶段 就 考虑 如 何在 应 用 中 弥 
合 不 同 网 络 的 差异 。 好 消息 是 ， 我 们 用 来 优化 无 线 网 络 的 各 种 手段 ， 在 其 他 场景 下 
也 能 带 来 更 好 的 用 户 体验 。 下 面 我 们 就 开始 吧 。 


5.2 无 线 网 络 的 类 型 

网 络 由 一 组 设备 互相 连接 构成 。 对 无 线 网 络 而 言 ， 无 线 电 是 通信 媒体 。 可 是 ， 同 为 
无 线 电 媒体 ， 应 用 范围 不 同 、 拓 扑 结构 不 同 、 使 用 场景 不 同 ， 相 应 的 网 络 技术 也 过 
然 不 同 。 下 面 ， 我 们 就 从 地 理 范 围 角度 对 无 线 网 络 技术 加 以 分 类 ( 表 5-1)。 


表 5-1: 无 线 网 络 的 类 型 





















































类 型 范围 应 用 标准 

个 人 局 域 网 (PAN) 个 人 活动 范围 内 替代 周边 设备 的 线 缆 蓝牙 、ZigBee、NFC 

局 域 网 (LAN) 一 栋 楼 或 校园 内 ” 有线 网 络 的 无 线 扩展 IEEE 802.11 (Wi-Fi) 

城 域 网 (MAN) 一 座 城市 内 无 线 内 联网 IEEE 802.15 (WiMax) 
广域网 (WAN) 世界 范围 内 无 线 网 络 蜂窝 (UMTS、LTE 等 ) 

















这 种 分 类 方式 既 不 全 面 ， 也 不 精确 。 很 多 技术 和 标准 最 初 都 源 自 某 个 特定 的 使 用 场 
景 ， 例 如 蓝牙 技术 最 初 就 是 针对 PAN 应 用 和 为 替代 线 缆 而 出 现 的 。 这 些 技术 随 着 
时 间 推 移 功 能 不 断 增 强 ， 应 用 范围 和 吞吐 量 也 不 断 扩 大 。 比 如 ， 蓝 牙 技 术 现 在 就 支 
持 在 高 带宽 使 用 场景 下 与 802.11 (Wi-Fi) 的 无 颖 互 操作 。 类 似 地 ，WiMAX 最 初 
的 应 用 场景 是 定点 无 线 连 接 ， 但 随 着 时 间 推 移 也 具备 了 移动 能 力 ， 从 而 成 为 了 其 他 
WAN 或 蜂窝 技术 的 替代 方案 。 


上 述 分 类 方式 的 关键 不 在 于 怎么 分 清 各 种 技术 之 间 的 界限 ， 而 在 于 突出 每 种 使 用 场 
景 下 的 宏观 差异 。 有 些 设备 的 供电 可 以 连绵 不 绝 ， 而 其 他 设备 则 需要 随时 考虑 节 省 
电量 。 有 些 需 要 Gbit/s 级 的 传输 速率 ， 而 有 些 生来 只 能 传输 儿 十 到 几 百 字 市 的 数据 
(如 NFC)。 有 些 应 用 需要 实时 在 线 ， 而 其 他 应 用 则 可 以 容许 延迟 。 正 是 包含 这 些 在 
内 的 很 多 因素 决定 了 每 种 网 络 的 最 初 特 点 。 然 而 ， 每 种 网 络 技术 一 旦 付 诸 应 用 ， 就 
会 进一步 发 展 。 电 池 容 量 越 来 越 大 ， 处 理 器 速度 越 来 越 快 ， 调 制 算法 越 来 越 先进 ， 
加 上 其 他 方面 的 改进 ， 使 得 每 种 无 线 标准 的 应 用 场景 和 性 能 都 得 到 了 扩展 。 



































[人 你 的 下 一 个 应 用 很 可 能 要 通过 移动 网 络 交 付 ， 而 它 同时 还 可 能 要 通过 NFC 
心 付款 、 通 过 蓝牙 实现 基于 WebRTC 的 P2P 通信 、 通 过 Wi-Fi 传输 高 请 视频 
由" 流 。 总 之 ， 无 线 应 用 不 可 能 局 限于 一 种 无 线 标准 ! 


























5.3 无 线 网 络 的 性 能 基础 


所 有 无 线 技术 都 有 自身 的 约束 和 局 限 。 然 而 ， 无 论 使 用 哪 种 无 线 技术 ， 所 有 通信 方 
法 都 有 一 个 最 大 的 信道 容量 ， 这 个 容量 是 由 相同 的 底层 原理 决定 的 。 事 实 上 ， 信 息 
论 之 父 克 劳 德 : 香农 对 此 给 出 了 一 个 确切 的 数学 模型 (公式 5-1) ， 这 个 模型 与 技术 


,2 





S 
C= BW x log, isa 


。 C 是 信道 容量 ,单位 是 bit/s; 

。 BW 是 可 用 带宽 ， 单 位 是 Hz 

。 S 是 信号 ，N 是 噪声 ， 单 位 是 W。 

尽管 存在 茶 种 程度 的 简化 ， 但 这 个 公式 涵盖 了 影响 大 多 数 无 线 网 络 性 能 的 所 有 基本 


因素 。 在 所 有 这 些 因素 中 ， 与 数据 传输 速度 最 直接 相关 的 就 是 接收 端 与 发 送 端 之 间 
的 可 用 带宽 和 信号 强度 。 





5.3.1 带宽 








有 线 网 络 通过 线 绕 将 网 络 中 的 各 个 市 点 连接 起 来 ， 而 无 线 电 通 信 本 质 上 则 是 一 个 共 
享 媒体 ， 它 靠 的 是 无 线 电 波 ， 或 者 专业 一 点 讲 ， 叫 做 电磁 辐射 。 为 实现 通信 ， 发 送 
端 与 接收 端 必须 事先 就 通信 使 用 的 频率 范围 达成 共识 ， 在 这 个 频率 范围 内 双方 可 


以 顺畅 地 交换 信息 。 
GHz 频带 。 





这 些 频率 范围 
































比如 ，802.11b 和 802.11g 在 所 有 Wi-Fi 设备 上 都 使 用 2.4~2.5 





的 确定 与 分 配 由 谁 负责 呢 ? 简单 来 说 ， 由 地 方 政府 负责 ( 见 图 


-1)。 在 美国 ， 频 带 分 配 权 掌握 在 FCC (Federal Communication Commission ， 联 邦 


ee 


国家 和 地 区 使 用 ， 








事实 上 ， 由 于 政府 规定 不 同 ， 有 些 无 线 技术 可 以 在 世界 上 某 些 


旧 在 另 一 些 国 家 和 地 区 就 无 法 使 用 。 另 外 ， 不 同 国家 也 经 常会 给 
相同 的 无 线 技术 分 配 不 同 的 频率 范 
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5-1: FCC 无 线 频谱 分 配 图 : 2300~3000MHz 频段 











抛 开 政治 因素 不 谈 ， 除 了 以 共有 频段 作为 信息 交互 的 基础 外 ， 影 响 性 能 的 最 主要 因 
素 就 是 频率 范围 的 大 小 (带宽 )。 根 据 香农 的 模型 (公式 5-1)， 信道 的 总 体 比 特 率 
与 分 配 的 带宽 呈正 比 。 换 句 话 说， 在 其 他 条 件 等 同 的 情况 下 ， 频 率 范 围 加 倍 ， 传 输 
速度 加 倍 。 比 如 ， 带 宽 从 20MHz 变 成 40MHz 可 以 让 信道 传输 速率 加 倍 ， 而 这 正 是 
802.11n 在 早期 Wi-Fi 标准 基础 上 提升 性 能 的 做 法 ! 


最 后 ， 值 得 一 提 的 是 ， 并 非 所 有 频率 范围 的 性 能 都 一 样 。 低 频 信 号 传输 距离 远 、 履 盖 
范围 广 〈 大 蜂窝 ) ， 但 要 求 天 线 更 大 ， 而 且 竞 争 激烈 。 另 一 方面 ， 高 频 信 号 能 够 传输 
更 多 数据 ， 但 传输 距离 不 远 ， 因 此 覆盖 范围 小 〈 小 蜂窝 ) ， 需 要 较 多 的 基础 设施 投入 。 









































[ 对 不 同 的 应 用 而 言 ， 不 同 的 频率 范围 价值 也 不 一 样 。 广 播 只 适合 低频 率 范 
心 围 ， 而 双向 通信 则 更 适合 使 用 较 小 的 蜂窝 ， 因 为 较 小 的 蜂 窟 能 提供 更 高 的 









































全 球 频谱 分 配 及 管制 简 史 
只 要 对 世界 无 线 通信 史 稍 有 涉猎 ， 就 不 可 避免 地 会 了 解 一 些 当前 频谱 分 配 和 管制 
方面 的 纷争 。 那 么 无 线 电 通信 的 历史 如 何 呢 ? 


在 无 线 电 产 业 发 展 初期 ， 任 何人 可 以 出 于 任何 目的 使 用 任意 频率 范围 。 直 到 1912 
年 美国 的 《无 线 电 法 》 签 署 生 效 ， 无 线 电 频 谱 才 揭 开 强制 许可 使 用 的 序幕 。 该 法 
案 最 初 的 动议 部 分 源 自 对 泰坦 尼克 号 沉没 的 调查 。 据 称 ， 如 果 当 时 附近 的 船只 都 
在 监听 适当 的 频率 ， 那么 就 有 可 能 避免 灾难 发 生 ， 至 少 可 以 让 更 多 人 获救 。 无 论 
如 何 ， 这 个 新 法 案 开 了 为 国际 和 美国 联邦 无 线 通信 立法 的 先河 。 此 后 ， 其 他 国家 
也 纷纷 效仿 。 


20 多 年 后 ，FCC 出 台 了 1934 年 《通信 法 》 自 此 之 后 ，FCC 就 一 直 负 责 美 国境 内 
的 频谱 分 配 ， 将 可 用 频谱 分 割 成 了 较 小 的 专用 频段 。 


ISM (Industrial Scientific, and Medical， 工业 、 科 研 和 医疗 ) 无 线 电 频段 就 是 一 个 
差异 化 分 配 的 例子 。 这 个 频段 是 1947 年 国际 电信 大 会 确定 的 ， 在 国际 上 得 到 了 
保留 。 现 代 无 线 通信 (如 Wi-Fi) 使 用 的 2.4~2.5 GHz (100 MHz) 和 5.725~5.875 
GHz (150 MHz) 就 属于 ISM 频段 。 而 且 ， 这 两 个 频段 也 被 视 为 “ 免 许可 频段 ”， 
即 任何 人 都 可 以 在 这 两 个 频段 组 建 自己 的 无 线 网络 (无 论 商用 还 是 私 用 )， 只 要 使 
用 的 硬件 达到 一 定 的 技术 要 求 (比如 发 射 功率 ) 即 可 。 


随 着 无 线 通信 需求 日 益 增 长 ， 很 多 政府 都 开始 举行 “频谱 拍卖 ”， 通 过 这 种 形式 出 
售 在 某 个 频段 发 射 信号 的 许可 (执照 )。 这 种 例子 非常 多 ， 但 2008 年 的 700MHz 
FCC 拍卖 比较 有 代表 性 。 当 时 ， 美 国境 内 698~806 MHz 的 频率 范围 被 以 195.92 
亿美 元 的 价格 拍卖 给 十 几 个 竞拍 者 (这 个 范围 被 进一步 细 分 )。 没 错 ， 的 确 是 
“ 百 ” 亿 级 的 价格 。 
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带宽 是 一 种 稀缺 、 昂 焉 的 资源 。 关 于 当前 分 配方 式 是 否 公平 的 讨论 不 绝 于 耳 ， 也 
有 很 多 相关 的 专著 出 版 。 放 眼 未 来 ， 有 一 件 事 是 确定 无 疑 的 : 这 种 争论 还 将 持续 
升温 。 





5.3.2 ”信和 号 强度 

除了 带宽 之 外 ， 无 线 通信 的 第 二 个 限制 因素 就 是 收发 两 端 之 间 的 信号 强度 ， 也 叫 信 
噪 比 (SNR，Signal Noise Ratio)。 本 质 上 ， 信 哄 比 衡量 的 是 预期 信号 强度 与 背景 噪 
声 及 干扰 之 间 的 比值 。 背 景 噪声 越 大 ， 携 带 信息 的 信号 就 必须 越 强 。 


本 质 上 ， 所 有 无 线 电 通信 使 用 的 都 是 共享 媒体 ， 因 此 别 的 设备 很 可 能 在 这 个 媒体 
中 产生 干扰 信号 。 比 如 ， 以 2.5 GHz 频率 工作 的 微波 炉 很 可 能 与 Wi-Fi 使 用 的 频率 
范围 重合 ， 从 而 产生 交叉 和 干扰。 此 外 ， 邻 居家 的 Wi-Fi 热 点， 甚至 同事 访问 同一 
Wi-Fi 网 络 的 笔记 本 电脑 ， 同 样 可 能 对 你 的 数据 传输 产生 干扰 。 


理想 情况 下 ， 你 应 该 是 某 一 频率 范围 内 的 唯一 用 户 ， 而 且 也 没有 背景 噪声 和 干扰 。 
可 惜 的 是 ， 这 是 不 现实 的 。 首 先 ， 带 宽 很 稀缺 ， 其 次 ， 要 实现 无 线 通信 必 须 有 很 多 
设备 参与 。 因 此 ， 如 果 想 在 存在 干扰 的 情况 下 达到 预期 的 数据 传输 速度 ， 要 么 增 大 
发 射 功率 ， 也 就 是 提高 信号 强度 ， 要 么 缩短 收发 两 端的 距离 一 一 或 者 双管齐下 。 



































4 4 ， 因 环境 而 异 。 关 于 这 方面 的 讨论 超出 了 本 书 范围 ， 如 果 你 好 奇 的 话 ， 可 以 
心 ， 自 己 搜 索 一 下 。 











增 sa， 
1 路 径 损耗 ， 或 叫 通路 衰减 ， 指 的 是 信号 强度 随 距 离 降低 。 实 际 的 降低 速率 





要 理解 信号 、 噪 声 、 发 射 功能 和 距离 之 间 的 关系 ， 可 以 想象 你 在 一 个 小 房间 里 跟 距 
离 你 6 米 远 的 一 个 人 说话 。 如 果 房 间 里 只 有 你 们 俩 人 ， 你 们 只 要 用 正常 音量 讲话 即 
可 。 但 是 ， 现 在 假设 房间 里 又 来 了 二 十 几 个 人 ， 就 像 一 个 拥挤 的 聚会 ， 每 个 人 都 在 
跟 另 一 个 人 说 话 。 突 然 之 间 ， 你 发 现 自己 根本 听 不 清 对 方 的 声音 了 ! 当然 ， 你 可 以 
提高 音量 ， 但 这 样 一 来 会 增 大 你 周围 每 个 人 的 “噪声 "。 于 是 ， 他 们 也 会 相应 地 提高 








:能 与 距离 自己 1 米 左右 的 人 对 话 〈 图 5-2)。 假 如 你 曾 在 吵 立 的 聚会 上 怎么 喊 也 没 
办 法 让 别人 听见 ， 或 者 曾 弯 下 腰 去 跟 和 人 大 声 说 话 ， 那 你 就 该 知道 什么 是 信 噪 比 了 。 
































图 5-2: 日 常生 活 中 小 区 (cell) 呼吸 及 远近 效应 
事实 上 ， 上 面 的 例子 演示 了 两 个 重要 的 效应 。 


。 远近 效应 
接收 端 捕获 较 强 的 信号 ， 因 而 不 可 能 检测 到 较 弱 的 信号 ， 实 际 上 是 “ 挤 出 ”了 园 
弱 的 信号 。 


。 小 区 呼吸 效应 
小 区 覆盖 范围 或 信号 传输 距离 基于 噪声 大 小 和 干扰 级 别 扩展 和 收缩 。 


你 旁边 一 个 或 多 个 大 声 讲话 的 人 会 阻挡 较 弱 的 信号 ， 从 而 产生 远近 效应 。 类 似 地 ， 
你 周围 交谈 的 人 越 多 ， 干 扰 就 越 严重 ， 能 让 你 识别 有 用 信号 的 范围 也 越 小 ， 这 就 是 
呼吸 效应 。 由 此 及 彼 ， 就 不 难 理解 各 种 无 线 电 通信 中 也 照样 存在 与 此 类 似 的 限制 了 ， 
而 且 这 种 限制 与 使 用 什么 通信 协议 和 底层 技术 无 关 。 





5.3.3 调制 

可 用 带宽 和 SNR 是 影响 任何 无 线 信 道 容量 的 两 个 主要 物理 因素 。 可 是 ， 用 于 编码 信 
号 的 算法 对 无 线性 能 同样 有 显著 影响 。 

简单 来 说 ， 我 们 数字 信号 (1 和 0) 需要 转换 成 模拟 信号 (无 线 电波 )。 调 制 指 的 就 
是 这 个 数 模 转换 过 程 ， 不 同调 制 算法 的 转换 效率 是 不 一 样 的 。 不 同 的 字母 数字 组 合 
与 符号 率 决定 了 信道 的 最 终 吞 吐 量 。 下 面 来 看 一 个 例子 : 

。 接收 端 和 发 送 端 每 秒 可 以 处 理 1000 个 脉冲 或 符号 (1000 波 特 ) ， 

。 传送 的 每 个 符号 代表 一 个 不 同 的 位 序列 ,由 选择 的 字母 数字 决定 (例如 ,2 位 序列 : 
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00、01、10、11) ; 
。 信道 的 比特 率 是 1000 波 特 x 2 比特 /符号 ， 即 每 秒 2000 比特 。 


选择 调制 算法 取决 于 可 用 的 技术 、 收 发 两 端的 计算 能 力 ， 以 及 SNR。 高 阶 调制 的 代 
价 是 针对 噪声 和 干扰 的 可 靠 性 降低 。 天 下 没有 免费 的 午餐 ! 











不 要 担心 ， 我 们 不 会 一 头 所 进 信 号 处 理 的 泥 淖 。 这 里 关键 是 要 理解 调制 算 
心 4 、 法 确实 会 影响 无 线 信道 的 容量 ， 但 同时 它 也 会 受到 SNR、 可 用 处 理 能 
局 ， 以 及 其 他 常见 制约 因素 的 影响 。 






































re 人 
5.4 测量 现实 中 的 无 线性 能 
我 们 关于 信号 理论 的 简明 教程 可 以 总 结 如 下 : 任何 无 线 网 络 ， 无 论 它 叫 什么 名 字 ， 
缩写 是 什么 或 者 修订 版 本 是 多 少 ， 其 性 能 归根 结 底 都 受 限 于 几 个 众所周知 的 因素 。 
特别 是 分 配给 它 的 带宽 大 小 和 收发 两 端的 信 噪 比 。 另 外 ， 所 有 利用 无 线 电 的 通信 都 : 


。 通过 共享 的 通信 媒体 〈 无 线 电波 ) 实现 ， 
。 在 管制 下 使 用 特定 频率 范围 ，; 
。 在 管制 下 使 用 特定 的 发 射 功率 

。 受 限 于 不 断 变化 的 背景 噪声 和 干扰 ; 

。 受 限 于 所 选 无 线 技术 的 技术 约束 ， 

。 受 限 于 设备 本 身 的 限制 ， 比 如 形状 、 电 源 ， 等 等 。 


所 有 无 线 技术 都 在 宣传 自己 的 峰值 或 最 大 数据 速率 。 比 如 ，802.11g 标准 的 最 大 传 
输 速 率 为 54 Mbit/s， 而 802.11n 标准 则 提高 到 了 600 Mbit/s。 类 似 地 ， 某 些 移动 运 
营 商 宣传 自己 能 通过 LTE 提供 100+ MBits 的 上 网 速度 。 然 而 ， 面 对 这 些 数 字 ， 必 
须知 道 的 是 ， 它 们 都 是 在 理想 条 件 下 的 结果 。 


什么 是 理想 条 件 ? 没 错 ， 带 宽 最 大 、 频 段 独 有 、 品 声 最 小 、 调 制 算法 最 优 ， 以 及 日 益 
普及 的 多 无 线 流 并 行 发 射 (MIMO，Mnultiple Input Multiple Output， 多 输入 多 输出 )。 
毋庸 讳言 ， 使 用 无 线 网 络 与 使 用 有 线 网 络 的 体验 可 能 (或 者 说 一 定 ) 相差 极 大 。 


以 下 仅 列 举 儿 个 影响 无 线 网 络 性 能 的 因素 : 

。 收发 端的 距离 ， 

。 当前 位 置 的 背景 噪声 大 小 ; 

。 来 自 同一 网 络 (小 区 ) 其 他 用 户 的 干扰 大 小 ; 
。 来 自 相 邻 网 络 〈 小 区 ) 其 他 用 户 的 干扰 大 小 ; 
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。 两 端 发 射 功率 大 小 ， 
。 处 理 能 力 及 调制 算法 。 


换 句 话说， 如 果 你 想得到 最 大 的 吞吐 量 ， 就 要 尽力 减少 可 控 的 噪声 和 干扰 ， 尽 量 缩短 
接收 端 与 发 射 端的 距离 ， 给 它们 必要 的 功率 ， 并 确保 两 端 都 选择 最 优 的 调制 方法 。 否 
则 ， 如 果 你 对 性 能 要 求 十 分 苘 刻 ， 干脆 还 是 使 用 有 线 吧 | 无 线 的 便捷 总 得 有 点 代价 。 


没 错 ， 度 量 无 线 网 络 的 性 能 并 不 容易 。 一 个 小 小 的 变化 ， 比 如 把 接收 端的 位 置 挪动 
十 几 厘 米 ， 传 输 速率 很 可 能 就 会 翻 倍 。 而 过 一 小 会 儿 ， 随 着 其 他 接收 设备 被 唤醒 并 
竞争 性 地 访问 同一 个 无 线 信 道 ， 很 可 能 又 会 导致 速率 减 六。 本 质 上 ， 无 线性 能 具有 
高 度 不 稳定 性 。 











最 后 请 大 家 注意 ， 以 上 讨论 关注 的 一 直 是 吞吐 量 。 这 是 不 是 说 延迟 不 重要 了 ? 当然 
不 是 ， 但 延迟 与 具体 的 无 线 技术 密切 相关 ， 我 们 接 下 来 分 别 讨论 。 
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Wi-Fi 工作 于 免 许 可 的 ISM 频段 ， 任 何人 在 任何 地 方 都 可 以 轻易 部 署 ， 必 要 的 硬件 
也 很 便宜 很 简单 。 毫 不 奇怪 ，Wi-Fi 已 经 成 为 如 今 最 流行 也 是 应 用 最 为 广泛 的 无 线 
技术 。 


Wi-Fi 是 Wi-Fi 联盟 (Wi-Fi Alliance) 的 注册 商标 ， 该 组 织 是 一 个 同业 公会 ， 致 力 
于 推广 无 线 LAN 技术 ， 同 时 提供 互 操作 标准 和 测试 。 从 技术 角度 说 ， 某 设备 如 果 
想 印 上 Wi-Fi 字样 及 标志 ， 必 须 经 过 Wi-Fi 联盟 的 认证 。 但 实践 中 ，Wi-Fi 可 以 用 
来 指称 任何 基于 IEEE 802.11 标准 的 产品 。 


802.11 协议 草拟 于 1997 年 ， 基 本 上 是 把 当时 的 以 大 网 标准 (IEEE 802.3) 照搬 到 
了 无 线 通信 和 领域 (基于 以 太 网 标准 改写 而 成 )。 然 而 ， 直 到 1999 年 802.11b 问世 后 ， 
Wi-Fi 设备 的 市 场 才 启动 。 由 于 这 种 技术 相对 简单 ， 部 署 简便 ， 而 且 工作 于 免 许 可 
的 2.4 GHz ISM 频段 ， 任 何人 都 可 以 利用 它 对 既 有 的 局 域 网 进行 “无 线 扩 展 ”。 今 
天 ， 几 乎 所 有 台式 机 、 笔 记 本 、 平 板 电脑 和 智能 手机 ， 乃 至 其 他 规格 形制 的 设备 都 
内 置 有 Wi-Fi 通信 模块 。 


6.1 从 以 太 网 到 无 线 局 域 网 


802.11 无 线 标准 主要 是 作为 既 有 以 太 网 标准 (802.3) 的 扩展 来 设计 的 。 事 实 上 ， 以 
太 网 通常 被 称 作 局 域 网 (LAN) 标准 ， 而 802.11 标准 族 (图 6-1) 则 相应 地 被 称 作 
无 线 局 域 网 (WLAN，Wireless LAN ) 标准 。 然 而 ， 熟 悉 历史 的 极 客 都 知道 ， 以 太 
网 协议 很 大 程度 上 借鉴 了 ALOHAnet 协议 ， 而 后 者 是 第 一 个 关于 无 线 网 络 的 协议 ， 











79 





由 夏威夷 大 学 开发 并 在 1971 年 对 外 公布 。 换 句 话 说 ， 我 们 只 是 忽 了 个 圈子 而 已 ! 























图 6-1; 802.3 (以 太 网 ) 和 802.11 (Wi-Fi) 的 数据 和 物理 层 


这 个 共同 点 非常 重要 ， 因 为 ALOHAnet 协议 影响 了 后 来 的 以 大 网 和 Wi-Fi 协议 调度 
通信 的 方式 。 事 实 上 ， 以 太 网 和 Wi-Fi 都 把 共享 媒体 (无论 是 线 绕 还 是 无 线 电 波 ) 
视 为 “随机 访问 通道 ”"， 即 没有 中 心 控制 环节 或 者 调度 中 心 控制 谁 或 哪 台 设 备 在 哪个 
时 刻 可 以 发 送 数据 。 相 反 ， 所 有 设备 都 自我 控制 ， 大 家 必须 协同 工作 ， 共 同 维护 共 
享 信道 的 性 能 。 





以 太 网 标准 过 去 依赖 于 概率 访问 的 CSMA (Carrier Sense Multiple Access， 载 波 监 
听 多 路 访问 ) 协议 ， 这 个 名 字 听 起 来 很 复杂 ， 实 际 上 就 是 “ 先 听 后 说 ”的 一 种 算法 。 
简单 来 说 ， 如 果 你 想 发 送 数 据 ， 那 么 先 要 : 


。 检查 是 否 有 人 正在 发 送 ， 
。 如 果 信 道 已 ， 监 听 并 等 待 信道 空闲 ， 
。 信道 空 亲 后 ， 立 即 发 送 数据 。 


当然 ， 任 何 信 号 传播 都 需要 花 时 间 ， 冲 突 也 时 有 发 生 。 为 此 ， 以 太 网 标准 也 增加 了 
冲突 检测 机 制 (CSMA/CD，Collision Detection) : 如 果 检 测 到 冲突 ， 则 双方 都 立即 
停止 发 送 数据 并 小 睡 一 段 随机 的 时 间 (后 续 时 间 以 指数 级 增长 )， 从 而 保证 发 生 冲 突 
的 发 送 端 不 会 同步 ， 且 不 会 同时 重新 开始 发 送 数据 。 


Wi-Fi 处 理 冲 突 的 方式 很 类 似 ， 但 也 稍 有 不 同 : 由 于 收发 无 线 电 的 硬件 所 限 ， 它 不 
能 在 发 送 数 据 期 间 检 测 到 冲突 。 实 际 上 ，Wi-Fi 采 用 的 是 冲突 避免 (CSMA/CA， 
Collision Avoidance) 机 制 ， 即 每 个 发 送 方 都 会 在 自己 认为 信道 空 闪 时 发 送 数 据 ， 
以 避免 冲突 。 为 此 ， 每 个 Wi-Fi 数据 帧 必须 明确 得 到 接收 方 的 确认 ， 以 确保 不 发 生 


冲突 。 











当然 ， 这 只 是 简单 地 概括 而 已 。 但 这 确实 是 以 太 网 和 Wi-Fi 针对 共享 媒体 调度 通信 
的 机 制 。 对 以 大 网 来 说 ， 媒 体 就 是 物理 线 缆 ， 对 Wi-Fi 而 言 ， 媒 体 则 是 无 线 信 道 。 


实践 中 ， 概 率 访问 模型 在 轻 负 载 网 络 中 表现 很 好 。 我 们 不 会 罗列 数学 证 明 ， 但 要 保 
证 良好 的 信道 利用 率 (冲突 最 小 化 )， 则 信道 负载 必须 低 于 10%。 保 持 低 负载 的 情 
况 下 ， 不 用 太 多 协调 和 调度 就 能 获得 理想 的 否 吐 能 力 。 但 是 ， 随 着 负载 增长 ， 冲 突 
次 数 也 会 迅速 增加 ， 造 成 整个 网 络 性 能 不 稳定 。 


高 负载 下 性 能 不 稳定 的 Wi-Fi 网 络 很 常见 ， 比 如 某 个 技术 大 会 现场 ， 访 问 
心 。 同 一 节点 的 客户 端 很 多 ， 这 时 候 的 Wi-Fi 网 络 很 可 能 就 不 稳定 。 当 然 ， 概 
“， 率 调度 并 不 是 造成 这 种 结果 的 唯一 因素 ， 但 无 疑 是 其 中 之 一 。 


6.2 ” ”Wi-Fi 标准 及 功能 
从 802.11b 开始 ，Wi-Fi 进入 日 常 应 用 。 但 是 ， 与 任何 流行 的 技术 一 样 ，IEEE 802 


标准 委员 会 并 没有 就 此 作罢 ， 而 是 继续 积极 地 发 布 新 协议 ( 表 6-1)， 以 支持 更 高 的 
吞吐 量 和 更 先进 的 调制 技术 、 多 流 (multi-streaming) 及 其 他 各 种 新 功能 。 


表 6-1，Wi-Fi 发 布 历史 及 路 线 图 


























802.11 协 议 ”发 布 时 间 频率 (GHz ) ”带宽 ( MHz ) 流速 率 ( Mbit/s ) 
b 1999-09 2.4 20 ly 2 $5 11 
g 2003-06 2.4 20 6、9、12、18、24、36、48、54 
7.2、14.4、21.7、28.9、43.3、57.8、 
2009-10 2.4 20 
65、72.2 
2009-10 5 40 15、30、45、60、90、120、135、150 
ac 2014 年 前 后 5 20、40、80、160 ”最 高 866.7 


今天 , b 和 g 标 准 已 经 得 到 非常 普遍 的 支持 。 这 两 个 标准 使 用 的 都 是 2.4 GHz 的 
ISM 频段 、20 MHz 带宽 ， 最 多 支持 一 个 无 线 电 数据 流 。 根 据 当地 管制 ， 发 射 功 率 
也 很 可 能 固定 在 最 大 200 mW。 有 些 路 由 器 支持 调整 发 射 功率 ， 但 很 可 能 会 被 区 域 
上 限 值 所 覆盖 。 


那 我 们 怎么 提升 未 来 Wi-Fi 网 络 的 性 能 呢 ? n 和 未 来 的 ac 标准 将 每 个 信道 的 带宽 
由 20 MHz 提升 到 40 MHz， 使 用 高 阶 调制 算法 ， 增 加 无 线 信 道 并 行 发 射 多 个 数据 流 
(MIMO ) 。 总 起 来 说 ， 在 理想 条 件 下 ，ac 无 线 标准 的 传输 速度 将 达到 Gbit/s 以 上 。 


6.3 测量 和 优化 Wi-Fi 性 能 


此 时 此 刻 ， 有 读者 可 能 会 说 ， 这 只 是 “理想 条 件 下 ”的 理论 速度 啊 ! 没 错 ，Wi-Fi 
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网 络 的 广泛 部 署 和 流行 也 导致 了 最 大 的 一 个 性 能 挑战 ， 小 区 内 部 和 外 部 干扰 。Wi-Fi 
标准 没有 规定 任何 中 央 调 度 机 制 ， 因 而 对 任何 客户 端的 吞吐 量 和 延迟 都 不 提供 保证 。 














新 的 WMM (Wi-Fi Multimedia，Wi-Fi 多 媒体 ) 扩展 会 在 无 线 电 接口 中 对 需要 低 延 
迟 的 应 用 (语音 、 视 频 等 ) 启用 基本 的 QoS (Quality of Service， 服 务 质量 ) ， 但 能 
识别 的 路 由 器 很 少 ， 能 识别 的 客户 端 就 更 少 了 。 与 此 同时 ， 你 的 网 络 内 部 和 附近 的 
Wi-Fi 网 络 一 定 会 争 用 共享 的 无 线 电 资源 。 





或 许 你 的 路 由 器 支持 对 网 络 中 的 客户 端 设置 一 些 QoS 策略 (比如 每 个 客户 端 或 每 
种 流量 类 型 的 最 大 速度 )， 但 对 于 附近 其 他 Wi-Fi 网 络 产 生 的 流量 ， 你 则 无 计 可 施 。 
Wi-Fi 网 络 之 所 以 无 处 不 在 ， 主 要 原因 就 是 它 部 署 简单 ， 而 正 因 为 部 署 简单 ， 才 会 
带 来 当前 的 性 能 问题 。 事 实 上 ， 在 城市 紧 华 地 段 或 者 写字 楼 中 ， 数 十 个 Wi-Fi 网 络 
重合 的 现象 并 不 罕见 (图 6-2)。 

































































2.4 GHz Channels 5 GHz Channels 














6-2: 在 inSSIDer 中 可 视 化 地 查看 重合 的 Wi-Fi 网 络 (2.4 GHz 和 5 GHz 频段 ) 


使 用 最 多 的 2.4 GHz 频段 提供 3 个 不 重 县 的 20 MHz 无 线 电 信道 : 1.6 和 11 (图 6-3)。 
当然 ， 并 不 是 所 有 国家 都 会 这 样 分 配 。 某 些 国家 可 能 会 允许 使 用 更 高 的 信道 (13、 
14)， 而 其 他 国家 则 可 能 会 限制 你 只 能 使 用 更 少 的 信道 。 但 抛 开 地 方 管制 不 论 ， 关 
键 是 要 知道 你 的 网 络 附近 远 远 不 只 有 两 三 个 Wi-Fi 网 络 ， 其 中 一 些 网 络 一 定 会 重 倒 ， 
从 而 共享 相同 频率 范围 内 的 带宽 。 











1 2 3 4 6 7 8 9 10 1 7172 3 14 Channel 
2.412 2.417 2.422 2.427 2.432 2.437 2.442 2.447 2.452 2.457 2.462 2.467 2.472 2.484 Center Frequency 








22 MHz 





6-3: 维基 百科 中 关于 2.4 GHz 频段 Wi-Fi 信道 的 示意 图 
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你 的 802.11g 客户 端 和 路 由 器 的 速度 可 能 是 S4 Mbit/s， 但 如 果 你 的 邻居 也 占用 了 相 
同 的 Wi-Fi 信道 ， 而 且 正在 实时 观看 高 清 视频 ， 那 你 的 带宽 就 会 减 至 一 半 ， 甚 至 还 
不 到 一 半 。 你 的 接 入 点 在 这 里 没有 发 言 权 ， 因 为 这 是 Wi-Fi 的 功能 ， 而 非 bug ! 


更 糟糕 的 是 ， 延 迟 性 能 也 好 不 到 哪 去 。 从 客户 端 到 Wi-Fi 接 入 点 的 第 一 跳 需要 多 长 
时 间 ， 也 是 没有 保证 的 。 在 网 络 重 全 严重 的 环境 下 ， 第 一 跳 所 需 的 时 间 可 能 是 儿 十 
ms， 也 可 能 是 几 百 ms。 因 为 你 需要 跟 同一 信道 内 的 其 他 无 线 客户 端 竞争 |! 


好 在 ， 如 果 你 积极 地 采用 新 技术 ， 那 很 可 能 显著 提升 Wi-Fi 网 络 的 性 能 。 新 的 
802.11n 和 802.11ac 标准 使 用 5 GHz 频段 ， 不 仅 拓 宽 了 频率 范围 ， 而 且 能 保证 在 多 
数 环境 下 不 发 生 冲 突 。 换 句 话说， 至 少 在 目前 ， 如 果 你 附近 没有 什么 〈 像 你 一 样 
的 ) 技术 大 牛 ， 那 么 一 台 双 频 路 由 器 (支持 2.4 GHz 和 5 GHz) 既 能 兼容 2.4 GHz 
的 老 客户 端 ， 也 能 为 支持 5 GHz 的 客户 端 提供 更 好 的 性 能 。 





测量 Wi-Fi 第 一 跳 的 延迟 时 间 
运行 ping 命令 是 估计 无 线 网 络 第 一 跳 延 迟 时 间 的 简便 方式 。 但 每 次 运行 的 结果 可 
能 不 同 ， 表 6-2 就 是 我 在 自己 家 里 测试 双 频 802.11n 路 由 器 得 到 的 结果 。 
表 6-2: 2.4 GHz 频段 和 5 GHz 频段 的 时 延 差 别 


频率 ( GHz ) 中 值 (ms) 195% (ms) |99% (ms) 
2.4 622 34.87 58.91 
5 0.90 1.58 7.89 





拥挤 的 2.4 GHz 闫 段 与 空闲 得 多 的 $ GHz 频段 (图 6-2) 性 能 差异 极 大 。2.4 GHz 
频段 中 十 几 个 重 登 的 网 络 导 致 第 一 跳 的 延迟 长 达 35 ms (95%)， 而 我 的 笔记 本 电 
脑 与 路 由 器 相距 还 不 到 6 米 。 











综 上 所 述 ， 我 们 提 到 了 关于 Wi-Fi 性 能 的 哪些 重要 因素 呢 ? 


。 Wi-Fi 不 保证 用 户 的 带宽 和 延迟 时 间 。 

。 Wi-Fi 的 信 噪 比 不 同 ， 带 宽 也 随 之 不 同 。 

。 Wi-Fi 的 发 射 功率 被 限制 在 200 mW 以 内 。 

。 Wi-Fi 在 2.4 GHz 和 较 新 的 5 GHz 频段 中 的 频谱 有 限 。 

。 Wi-Fi 信道 分 配 决 定 了 接 入 点 信号 会 重生。 

。 Wi-Fi 接 入 点 与 客户 端 争 用 同一 个 无 线 信道 。 

简单 来 说 ， 根 本 不 存在 什么 “典型 的 ”Wi-Fi 性 能 。 选 用 的 标准 、 用 户 的 位 置 、 使 
用 的 设备 ， 以 及 本 地 无 线 电 环 境 决定 了 频率 范围 各 不 相同 。 如 果 你 是 唯一 的 Wi-Fi 
用 户 ， 那 可 以 指望 获得 最 大 的 否 吐 量 、 最 低 的 延迟 ,以 及 这 两 者 的 稳定 状态 。 可 如 
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果 你 是 跟 其 他 人 共享 一 个 接 入 点 ， 而 且 近 旁 还 有 其 他 Wi-Fi 网 络 ， 那 可 就 没 法 说 了 ， 
带宽 和 延迟 都 会 高 度 不 稳定 。 


Wi-Fi 中 的 丢 包 

Wi-Fi 网 络 的 设计 天 然 会 导致 多 个 客户 端的 大 量 冲 突 。 然 而 ， 即 便 如 此 ， 也 不 一 定 
会 导致 更 高 的 丢 包 率 。 所 有 Wi-Fi 协议 的 数据 和 物理 层 实现 都 有 自己 的 重 发 和 纠 错 
机 制 ， 这 些 机 制 向 上 层 隐 藏 了 重 发 操作 。 


换 句 话说 ，TCP 丢 包 在 Wi-Fi 网 络 中 同样 存在 ， 因 而 其 TCP 层 的 传输 速度 不 及 大 多 
数 有 线 网 络 。 除 了 直观 的 层 包 问题 ，Wi-Fi 网 络 更 突出 的 问题 则 是 分 组 到 达 时 间 差 
异 极 大 ， 这 一 切 都 要 归 和 人 条 于 数据 链 路 层 和 物理 层 的 冲突 及 重 发 。 









































Ie 事实 上 ， 在 802.11n 之 前 ，Wi-Fi 协议 只 允许 同一 时 刻 传输 一 个 数据 帧 ， 这 
心 。 一 帧 必须 得 到 链 路 层 的 确认 才能 继续 发 送 下 一 帧 。802.1ln 则 引入 了 新 的 
全 “ 帧 聚合 ”功能 ， 从 而 支持 同时 发 送 和 确认 多 个 Wi-Fi 数据 帧 。 





6.4 针对 Wi-Fi 的 优化 建议 


前 面 从 整体 上 介绍 了 Wi-Fi 网 络 突出 的 性 能 特点 。 实 践 中 的 Wi-Fi 网 络 都 还 挺 够 用 ， 
而 且 其 部署 的 简便 性 更 是 没 法 比拟 。 事 实 上 ， 目 前 不 支持 Wi-Fi 的 计算 机 、 手 机 或 
平板 并 不 多 见 ， 而 接 入 以 太 网 的 设备 却 常常 需要 外 围 设备 支持 。 


有 了 这 个 总 体 认 识 ， 就 可 以 讨论 你 的 应 用 能 否 通过 优化 Wi-Fi 网 络 受益 了 。 











6.4.1 利用 不 计 流 量 的 带宽 

现实 当中 的 Wi-Fi 网 络 一 般 都 是 有 线 局 域 网 的 扩展 ， 而 有 线 局 域 网 可 能 又 通过 
DSL、 有 线 电视 网 或 者 光纤 连接 到 广域网 。 对 于 一 般 的 美国 人 ， 平 均 上 网 带宽 为 6.7 
Mbit/s， 而 全 球 平均 带宽 是 2.6 Mbit/s (参见 表 1-2) 。 换 名 话说 ， 大 多 数 Wi-Fi 的 速 
度 最 终 仍 受 限于 WAN 的 带宽 ， 而 不 是 其 自身 带宽 。 总 之 ， 无 线 网 络 通信 风景 这 边 
独 好 ! 

不 过 ， 除 了 带宽 瓶颈， 这 也 意味 着 Wi-Fi 网 络 通常 要 背 靠 不 计 流 量 的 WAN 连 
接 一 一 就 算是 有 流量 限制 ， 其 流量 上 限 或 吞吐 量 往往 也 会 很 高 。 因 此 ， 很 多 3G 或 
4G 用 户 由 于 成 本 和 带宽 原因 不 愿 下 载 大 文件 ， 但 Wi-Fi 用 户 则 不 用 担心 这 个 问题 。 
当然 ， 不 计 流 量 只 是 针对 大 多 数 情 况 而 言 的 ， 如 果 Wi-Fi 接 入 点 后 面 是 一 个 3G 或 
4G 连接 ， 那 得 另 当 别论 。 基 于 这 个 事实 ， 下 载 大 文件 、 升 级 软件 、 流 式 播放 等 应 用 
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都 可 以 放心 地 通过 Wi-Fi 来 做 。 换 名 话说 ， 如 果 用 户 要 做 这 些 事 ， 别 忘 了 提醒 他 们 
切换 到 Wi-Fi 网 络 上 去 1 








El 3 

ev 很 多 移动 运营 商都 推荐 大 数据 应 用 “把 流量 转移 到 Wi-Fi 上 ”， 要 么 提醒 用 

4 4 、 户 切换 到 Wi-Fi， 要 么 在 可 能 的 情况 下 利用 Wi-Fi 在 后 台 进 行 数据 同步 或 
必 ， 大 数据 转移 。 





6.4.2 ”适应 可 变 带 宽 

如 前 所 述 ，Wi-Fi 不 保证 带宽 和 延迟 时 间 。 用 户 的 路 由 器 如 果 设 置 应 用 级 别 的 QoS 
策略 ， 那 可 能 会 为 同一 无 线 网 络 中 的 客户 端 提供 一 个 公平 的 环境 。 然 而 ，Wi-Ei 无 
线 接口 自身 对 QoS 的 支持 非常 有 限 。 更 糟糕 的 是 ， 在 多 个 重合 的 Wi-Fi 网 络 中 根本 
没有 QoS 策略 。 


于 是 ， 每 个 客户 端的 实际 带宽 可 能 因 位 置 、 附 近 无 线 客户 端的 活动 情况 ， 以 及 无 线 
大 环境 而 每 秒 钟 都 会 有 所 不 同 。 


举 个 例子 ， 高 清 视 频 流 要 求 带 宽 为 每 秒 达 到 Mbit 级 别 ( 表 6-3)， 尽 管 大 多 数 Wi-Fi 
标准 在 理想 情况 下 都 能 满足 这 个 要 求 ， 但 实际 应 用 中 吞吐 量 间 隙 下降 的 情况 并 不 少 
见 。 由 于 Wi-Fi 网 络 的 带宽 天 生 具 有 不 确定 性 ， 因 此 我 们 不 能 也 不 应 该 指望 未 来 的 
下 载 比特 率 比 过 去 高 多 少 。 在 视频 一 开始 下 载 时 就 测试 带宽 速率 ， 可 能 会 因 回 放 期 
间 无 线条 件 的 变化 ， 而 导致 断断续续 的 缓冲 暂停 。 


表 6-3; 采用 H.264 视 频 编 解码 方案 的 YouTube 示 例 视 频 的 比特 率 

















容器 视频 分 辩 率 编码 比特 率 ( Mbit/s ) 
mp4 360p H.264 0.5 

mp4 480p H.264 1~1.5 

mp4 720p H.264 2~2.9 

mp4 1080p H.264 3~4.3 


虽然 我 们 不 能 预测 可 用 带宽 ， 但 我 们 可 以 ,而且 也 应 该 利用 连续 的 测量 技术 ， 比 如 
自 适应 比特 流 ， 来 主动 适应 带宽 变化 。 





自 适应 比特 流 


自 适 应 比特 率 并 不 适合 所 有 资源 ， 但 对 视频 和 音频 这 样 的 长 时 间 流 服务 是 非常 合 
适 的 。 
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对 视频 而 言 ， 资 源 可 能 会 使 用 多 种 比特 率 编 码 和 存储 ， 然 后 切割 为 多 个 部 分 ( 比 
如 ，YouTube 视频 会 分 成 多 个 5~10s 的 块 )。 然 后 ， 在 客户 端 下 载 视频 流 期 间 ， 客 
户 端 或 服务 器 可 以 监控 每 个 视频 块 的 下 载 速 度 ， 必 要 时 根据 带宽 的 变化 调整 要 下 
载 的 下 一 个 视频 块 的 比特 率 。 事 实 上 ,现实 中 的 视频 服务 ， 开 始 一 般 是 低 比 特 率 
的 视频 块 ， 以 便 视频 播放 能 更 快 开始 。 然 后 ， 再 根据 可 用 带宽 的 动态 变化 调整 后 
续 视频 块 的 比特 率 。 

每 个 资源 要 分 别 创建 多 少 个 比特 率 版 本 呢 ? 取决 于 你 的 应 用 | 不 过 ， 我 可 以 告诉 
你 ，Netflix 为 适应 不 同 的 屏幕 大 小 和 可 用 带宽 ， 为 每 个 视频 流 都 创建 了 超过 120 
个 版 本 ! 让 用 户 有 流畅 感 、 实 时 感 ， 可 真 不 是 件 简单 的 事 儿 。 











6.4.3 ”适应 可 变 的 延迟 时 间 
Wi-Fi 既 不 保证 带宽 ， 也 不 保证 第 一 跳 的 延迟 时 间 。 如 果 要 经 过 不 止 一 跳 (比如 使 
用 无 线 网 桥 作 为 接 入 点 时 )， 那 预测 延迟 时 间 就 更 困难 了 。 


理想 情况 下 ， 如 果 没 有 干扰 并 且 网 络 不 满载 ， 那 么 第 一 跳 的 延迟 时 间 不 会 超过 1 ms， 
而 且 非 常 稳定 。 然 而 ,现实 当中 ， 特 别 是 高 密度 的 城区 或 办 公 楼 环境 下 ， 儿 十 个 
Wi-Fi 接 入 点 和 客户 端 会 形成 激烈 的 频率 争 用 局 面 。 


结果 ， 第 一 跳 中 值 1~10 ms， 后 续 中 继 的 延迟 时 间 10~50 ms 都 是 合理 的 。 在 比较 精 
糕 的 情况 下 ， 高 达 几 百 毫 秒 也 并 非 不 可 能 。 


如 果 你 的 应 用 最 怕 高 延迟 ， 那 就 要 考虑 在 通过 Wi-Fi 运行 时 怎么 调整 其 行为 。 事 
实 上 ， 有 时 候 使 用 提供 不 可 靠 UDP 传输 的 WebRTC 倒 不 失 为 一 个 明智 的 选择 。 
当然 ， 传 输 方式 的 切换 不 能 挽救 无 线 网 络 ， 但 却 有 助 于 降低 协议 和 应 用 导致 的 延 
迟 时 间 。 
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据 估计 ， 到 2013 年 上 半年 ， 全 球 移动 上 网 设备 大 约 为 64 亿 台 。IDC 市 场 分 析 报 告 
称 ， 仅 2012 年 智能 上 网 设备 〈 智 能 手机 、 平 板 电脑 、 笔 记 本 电脑 、 台 式 电脑 等 ) 的 

货 量 就 为 11 亿 台 。 然 而 ， 更 令 人 震惊 的 则 是 新 设备 出 货 量 会 呈 直 线 增 长 : 同一 份 
IDC 报告 预测 ， 到 2016 年 ， 新 设备 出 货 量 将 达到 18 亿 台 。 累 计 起 来 ， 到 2020 年 
全 球 移动 上 网 设备 将 突破 200 亿 台 。 


2012 年 的 全 球 人 口 约 为 70 亿 ，2020 年 将 增 至 75 亿 。 两 个 增长 趋势 一 比 ， 就 可 以 
看 出 人 类 对 智能 上 网 设备 的 需求 是 没有 止境 的 。 很 明显 ， 我 们 中 的 大 多 数 人 都 不 会 
满足 于 只 拥有 一 部 移动 上 网 设备 ! 


然而 ， 上 网 设备 的 总 数 只 是 整个 蓝图 的 一 小 部 分 。 高 速 增长 的 出 货 量 背后 ， 是 对 同 
样 没 有 止境 的 高 速 连接 、 无 所 不 在 的 无 线 接 入 点 ， 以 及 驱动 这 些 新 设备 的 在 线 服务 
的 需求 。 因 为 如 此 ， 本 章 才 会 讨论 CDMA、GSM、HSPA 和 LTE 等 各 种 蜂窝 通信 
技术 的 性 能 问题 。 我 相信 ， 你 的 大 多 数 用 户 都 会 使 用 这 些 技 术 中 的 一 种 访问 你 的 站 
点 或 服务 。 赌 注 很 高 ， 前 景 很 诱 人 ， 我 们 必须 想 办 法 赢 下 来 。 然 而 一 提 到 性 能 ， 移 
动 网 络 的 一 些 设 计 方 面 的 挑战 就 展现 在 了 我 们 面前 。 


7.1 G 字 号 移动 网 络 简介 
如 果 要 全 面 解读 各 种 蜂窝 通信 标准 ， 它 们 的 版 本 ， 以 及 每 种 技术 的 优 劣 势 ， 那 几 章 


的 篇 幅 肯 定 不 够 ， 至 少 要 用 几 本 书 的 篇 幅 。 我 们 可 没有 那么 雄心 勃勃 ， 在 此 我 们 只 
想 束 主宰 未 来 无 线 技术 的 几 种 主要 技术 ( 表 7-1)， 讨 论 一 下 它们 的 运作 特点 ， 以 及 
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这 些 特 点 带 来 的 问题 。 


表 7-1: 四 代 移动 网 络 











Is 峰值 数据 速率 说 明 

1G 无 数据 模拟 系统 

2G Kbit/s 第 一 代数 字 系 统 ， 作 为 对 模拟 系统 的 标 代 或 与 乙 并 存 
3G Mbit/s 专用 数字 网 络 ， 与 模拟 系统 并 行 部 署 

4G Gbit/s 数字 及 分 组 网 络 


首先 要 知道 一 个 重要 概念 ， 即 每 一 代 无 线 技术 都 以 其 峰值 频谱 效 府 (bps/Hz) 为 标 
志 ， 为 了 让 用 户 更 直观 地 理解 ， 这 个 效率 会 转换 成 数据 传输 速率 ， 比 如 4G 网 络 的 
传输 速率 以 Gbit/s 来 衡量 。 注 意 ， 前 面 提 到 了 一 个 重要 的 关键 词 : 峰值 ! 提 到 这 个 
词 ， 大 家 可 以 回想 一 下 5.4 节 “测量 现实 中 的 无 线性 能 ”中 的 介绍 ， 所 谓 “峰值 ” 
指 的 是 理想 条 件 下 测 得 的 传输 速率 。 

无 论 什 么 标准 ， 每 种 网 络 真实 的 性 能 都 会 因 提 供 商 以 及 他 们 对 网 络 的 配置 、 每 个 小 
区 内 活跃 用 户 的 数量 、 特 定位 置 的 无 线 环境 、 使 用 的 设备 ， 以 及 影响 无 线性 能 的 其 
他 因素 而 异 。 明 确 了 这 个 大 前 提 ， 我 们 就 可 以 合理 地 调整 自己 对 性 能 的 预期 ， 比 如 
对 数据 吞吐 量 可 以 按 下 界 来 估计 ， 而 对 分 组 延迟 时 间 则 可 以 按 上 界 来 估计 ( 表 7-2)。 


表 7-2: 活动 移动 连接 的 数据 速率 和 延迟 时 间 























人 数据 速率 延迟 时 间 
2G 100~400 Kbit/s 300~1000 ms 
3G 0.5~5 Mbit/s 100~500 ms 
4G 1~50 Mbit/s <100ms 


当然 ， 问 题 还 会 更 复杂 ， 因 为 所 谓 3G 或 4G 的 分 类 法 其 实 很 粗糙 ， 相 应 地 吞吐 量 及 
延迟 时 间 也 就 更 粗放 了 。 为 了 搞 清楚 这 里 到 底 有 什么 事 ， 以 及 这 个 产业 的 发 展 趋势 ， 
我 们 首先 要 了 解 一 下 这 些 技术 的 历史 ， 包 含 技术 发 展 背 后 的 主要 推动 者 。 


7.1.1 最 早 提供 数据 服务 的 2G 

最 早 的 商业 1G 网 络 于 1979 年 部 署 于 日 本 。 这 种 网 络 属于 模拟 系统 ， 没 有 数据 传输 
能 力 。1991 年 ， 芬 兰 基 于 新 兴 的 GSM (Global System for Mobile communications ， 
全 球 移动 通信 系统 ) 标准 建设 了 第 一 个 2G 网 络 ， 最 早 在 无 线 电网 络 中 引入 了 数字 
信 令 。 这 个 网 络 支 持 基 于 电路 交换 的 移动 数据 服务 ， 比 如 短信 (SMS)， 而 且 数 据 传 
输 速率 达到 了 惊人 的 9.6 Kbit/s ! 








直到 1990 年 代 中 期 ，GPRS (General Packet Radio Service， 通 用 无 线 分 组 业务 ) 被 
引入 GSM 标准 ， 无 线 互联 网 才 真 正 走向 实用 。 当 然 ， 速 度 可 能 是 很 慢 的 : GPRS 传 
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输 速 度 能 达到 172 Kbit/s， 往 返 时 间 通 常 为 几 百 ms。GPRS 与 早期 2G 语音 技术 的 
结合 通常 被 称 为 2.5G。 几 年 后 ， 这 些 网 络 又 加 入 了 EDGE (Enhanced Data rates for 
GSM Evolution，GSM 增强 数据 率 演进 ) 功能 ， 将 峰值 速率 提高 到 384 Kbit/s。 第 一 
个 EDGE 网 络 (2.75G) 是 2003 年 在 美国 建成 的 。 








此 后 ， 进 入 了 一 个 停 沸 或 者 叫 调整 期 。 无 线 通 信 产 业 发 展 了 儿 和 十 年 ， 而 实用 、 面 向 
消费 者 的 移动 网 络 数据 服务 还 是 最 近 才 出 现 的 ! 2.75G 网 络 儿 乎 延 用 了 10 年 ， 虽 
然 是 昨天 的 技术 ， 但 在 世界 各 地 仍然 广泛 使 用 。 可 今天 ， 如 果 没 有 了 高 速 无 线 网 络 ， 
很 难 想象 将 是 一 番 什 么 样 的 景象 。 无 线 技术 的 应 用 之 广 、 发 展 之 快 令 人 咋舌 。 











7.1.2 3GPP 与 3GPP2 

随 着 消费 者 对 无 线 数据 服务 的 需求 开始 增长 ， 无 线 电网 络 互通 变 成 了 热门 话题 。 对 网 
络 运 营 商 而 言 ， 他 们 必须 购买 和 部 署 无 线 接 入 网 络 (RAN) 的 硬件 ， 而 这 需要 巨额 
投资 和 持续 维护 的 成 本 。 显 然 ， 标 准 的 硬件 能 降低 成 本 。 类 似 地 ， 在 缺乏 行业 标准 的 
情况 下 ， 用 户 只 能 使 用 自己 的 家 庭 网 络 ， 这 就 限制 了 移动 数据 访问 的 用 途 和 便捷 性 。 














作为 回应 ，ETSI (European Telecommunication Standards Institute， 欧 洲 电 信 标 准 
协会 ) 在 1990 年 代 初 期 制定 了 GSM 标准 ， 该 标准 迅速 被 很 多 欧洲 国家 采用 ， 并 在 
全 球 推广 。 事 实 上 ，GSM 应 该 是 部 署 最 广泛 的 无 线 标准 。 据 估计 ，GSM 占据 了 整 
个 移动 通信 市 场 80%~85% 的 份额 。 但 它 并 不 是 唯一 的 标准 ， 与 之 同时 ， 美 国 高 通 
公司 的 IS-95 标准 也 占据 了 10%~15% 的 市 场 份额 ， 主 要 部 署 在 北美 地 区 如 图 7-1 所 
示 。 于 是 ， 为 IS-95 无 线 网 络 设计 的 设备 不 能 在 GSM 网 络 中 使 用 ， 反 之 亦 然 。 相 信 
经 常 出 国 的 读者 一 定 对 此 深 有 感触 。 
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7-1: 2003~2007 年 移动 标准 市 场 份额 ( 引 自 维基 百科 ) 
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1998 年 ， 在 认识 到 既 有 标准 需要 全 球 演进 之 后 ， 同 时 也 为 了 制定 下 一 代 网 络 (3G) 
的 标准 ，GSM 和 IS-95 组 织 又 成 立 了 两 个 全 球 ， 竹 的 合作 伙伴 项 目 。 


。 3GPP (3rd Generation Partnership Project， 第 三 代 合 作 伙 伴 项 目 ) 
负责 人 和 定 UMTS (Universal Mobile Telecommunication System， 通 用 移动 通信 系 
统 )， 这 是 3G 技术 与 GSM 技术 结合 的 产物 。 这 个 项 目 后 来 也 负责 维护 GSM 标 
准 和 制定 新 的 LTE 标准 。 


3GPP2 (3rd Generation Partnership Project 2) 
负责 基于 CDMA2000， 也 就 是 高 通 制定 的 IS-95 标准 的 后 续 技 术 制 定 3G 规范 。 


结果 ， 两 种 标准 ( 表 7-3) 及 相关 的 网 络 基础 设施 并 行 推进 。 尽 管 步 调 可 能 不 一 致 ， 
但 它们 的 底层 技术 大 体 都 遵循 了 类 似 的 发 展 路 线 。 


表 7-3: 3GPP 和 3GPP2 开 发 的 蜂窝 网 络 标准 











1 组 织 发 布 版 
2G 3GPP GSM 
3GPP2 IS-95 (CDMAI1) 
2.5G、2.75G 3GPP GPRS、 EDGE (EGPRS) 
3GPP2 CDMA2000 
3G 3GPP UMTS 
3GPP2 CDMA2000 lx EV-DO Release 0 
3.3G, 3,75G, 3.9G 3GPP HSPA、HSPA+、LTE 
3GPP2 EV-DO Revision A、EV-DO Revision B、EV-DO Advanced 
4G 3GPP LIE-Advanced、HSPA+ Revision 11+ 


相信 读者 能 在 这 里 看 到 自己 的 熟悉 的 字眼 儿 : EV-DO、HSPA、LTE。 很 多 网 络 运 
营 商都 投入 了 大 量 资源 ， 并 且 还 将 一 直 投 入 下 去 ， 以 推广 这 些 他 们 所 谓 的 “最 新 最 
快 的 移动 数据 网 络 ”"。 不 过 ， 我 们 关注 这 些 历史 问题 可 不 是 为 了 营销 ， 而 是 为 了 从 
宏观 上 把 握 移 动 无 线 产 业 的 演进 : 








。 世界 上 部 署 了 两 个 主导 的 移动 网 络 ， 
。 3GPP 和 3GPP2 共同 管理 每 种 技术 的 演进 ; 
。 3GPP 和 3GPP2 标准 不 支持 设备 互 操作 。 





站 4G 或 3G 技术 。ITU (International Telecommunication Union， 国 际 
电信 联盟 ) 负责 规划 每 一 代 无 线 网 络 的 国际 标准 和 性 能 特点 ， 比 如 数据 传输 速率 和 
延迟 时 间 ， 而 3GPP 和 3GPP2 则 负责 制定 相关 标准 ， 在 各 自 相 关 技 术 的 条 件 下 满足 
甚至 超过 规划 的 预期 。 











怎么 知道 你 的 运营 商 在 运行 什么 网 络 ? 很 简单 ， 你 的 手机 有 SIM 卡 吗 ? 如 

必 ' 4 、 果 有 ， 那 就 是 源 自 GSM 的 3GPP 技术 。 要 了 解 有 关 网 络 的 更 多 信息 ， 可 以 

全 ”再 咨询 运营 商 ， 或 者 如 果 手 机 支持 ， 可 以 直接 查看 自己 手机 上 的 网 络 信息 。 
Android 用 户 ， 打 开 手 机 ， 调 出 拨号 盘 ， 输 入 : *#*#4636#*#*。 如 果 和 手机 
允许 执行 该 命令 ， 那 应 该 看 到 一 个 诊断 屏幕 ， 从 中 可 以 看 到 移动 连接 的 类 
型 、 电 字 诊 断 信 息 ， 等 等 。 














7.1.3 3G 技 术 的 演进 


3G 网 络 存在 两 个 主导 且 互 不 兼容 的 标准 : UMTS 和 CDMA， 分 别 由 3GPP 和 
3GPP2 制定 。 然 而 ， 就 像 早 期 的 蜂窝 标准 一 样 ， 这 两 种 标准 各 自 都 有 自己 的 过 渡 性 
版 本 ， 通 常 被 称 为 3.5G、3.75G 和 3.9G ( 表 7-3)。 














为 什么 不 直接 跳 到 4G 呢 ? 因为 制定 一 个 新 标准 需要 很 长 时 间 ， 而 且 更 重要 的 是 ， 
建设 新 网 络 需 要 巨额 投资 。 稍 后 我 们 会 介绍 到 ，4G 的 无 线 电 接口 及 基础 设备 完全 
同 于 3G。 为 此 ， 也 为 了 很 多 购买 了 3G 设备 的 用 户 的 利益 ，3GPP 和 3GPP2 一 直 在 
既 有 的 3G 标准 基础 上 改进 ， 而 这 也 能 让 运营 商 渐 进 地 升级 既 有 网 络 ， 为 现 有 用 户 
提供 更 好 的 性 能 





毫 无 疑问 ，3G 网 络 每 一 种 新 标准 的 吞吐 量 、 延 迟 时 间 及 其 他 性 能 指标 都 有 所 提升 ， 
某 些 情况 下 甚至 提升 非常 大 。 实 际 上 ， 从 技术 角度 讲 ，LTE 仍然 属于 3.9G 的 过 渡 
性 标准 ! 然而 ， 在 介绍 LTE 之 前 ， 让 我 们 先 了 解 一 下 3GPP 和 3GPP2 的 各 种 里 程 
碑 性 标准 。 

1. 3GPP 技 术 的 演进 〈 表 7-4 ) 

表 7-4，3GPP 发 布 历史 





版 本 年 份 说 明 

99 1999 UMTS 标准 的 第 一 个 版 本 

4 2001 增加 全 人 P 核心 网 络 

5 2002 增加 HSDPA (High Speed Downlink Packet Access) 
6 2004 增加 HSUPA (High Speed Uplink Packet Access) 

7 2007 增加 HSPA+ (High Speed Packet Access Evolution) 
8 2008 增加 LTE SAE (System Architecture Evolution ) 

9 2009 改进 SAE 与 WiMAX 的 互 操作 性 

10 2010 增加 4G LTE-Advanced 架构 
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在 3GPP 制定 的 标准 中 ，HSDPA (High Speed Downlink Packet Access， 高 速 分 组 
下 行 接 入 ) 和 HSUPA (High Speed Uplink Packet Access， 高 速 分 组 上 行 接 入 ) 通 
常 被 合 称 为 HSPA (High Speed Packet Access， 高 速 分 组 接 入 ) 。 这 两 个 标准 使 实际 
的 吞吐 量 达到 了 一 位 数 的 Mbit/s 级 别 ， 在 早期 3G 网 络 基 础 上 有 了 明显 提升 。HSPA 
网 络 经 常 被 为 3.5G。 


此 后 ， 下 一 个 新 版 本 是 HSPA+ (3.75G)， 这 个 版 本 由 于 引入 了 简化 的 核心 网 络 架 
构 ， 降 低 了 延迟 时 间 ， 同 时 数据 传输 速率 也 实现 了 一 位 数 Mbit/s 级 别 吞 吐 量 从 中 速 
到 高 速 的 提升 。 不 过 ，HSPA+ 还 不 是 终点 ， 自 发 布 之 日 起 ， 该 版 本 仍然 不 断 改进 ， 
目前 仍然 在 跟 LTE 和 LTE-Advanced 分 庭 抗 礼 | 

2. 3GPP2 技 术 的 演进 ( 表 7-5) 

表 7-5， 3GPP2 CDMA2000 1x EV-DO 标 准 的 发 布 历史 

















版 本 年 份 说 明 

Rel.0 1999 1x EV-DO 标准 的 第 一 个 版 本 

Rev. A 2001 提升 峰值 数据 速率 、 降 低 延 时 、QoS 
Rev.B 2004 在 Rev. A 基础 上 增加 多 运营 商 支持 
Rev.C 2007 改进 核心 网 络 效率 及 性 能 











CDMA2000 EV-DO 标准 是 由 3GPP2 沿 着 类 似 的 升级 路 径 制 定 的 。 第 一 版 (Rel. 0) 把 
下 行 吞 吐 量 提升 到 一 位 数 Mbit/s 级 别 。Rev. A 则 提升 了 上 行 速 率 ， 更 进一步 ， 上 下 
行 速率 在 Rev. B 中 同时 得 到 提升 。 实 际 上 ，Rev. B 网 络 的 吞吐 量 已 经 达到 了 一 位 数 
Mbits 级 别 的 中 高 级 水 平 ， 能 够 与 HSPA 及 HSPA+ ( 即 3.5G 和 3.75G) 网 络 媲 


随后 的 Rev. C 经 常 被 称 为 EV-DO Advanced， 它 在 容量 和 性 能 方面 有 了 很 大 提升 。 
但 是 ，EV-DO Advanced 的 采 标 率 并 没有 达到 HSPA+ 那样 的 水 平 。 为 什么 ? 仔细 看 
一 看 各 代 标 准 ( 表 7-3)， 就 会 发 现 3GPP2 没有 发 布 正式 的 、 竞 争 性 的 4G 标准 | 


虽然 3GPP2 可 以 继续 改进 其 CDMA 技术 ,但 有 一 天 ， 网 络 运营 商 和 网 络 提供 商 一 
致 认 可 3GPP LTE 是 各 种 网 络 共同 的 下 一 代 4G 标准 。 因 此 ， 很 多 CDMA 网 络 运 
营 商 也 率先 投资 建设 了 早期 的 LTE 基础 设施 ， 以 便 在 某 种 程度 上 保持 对 演进 中 的 
HSPA+ 的 竞争 力 。 


换 名 话说， 世界 上 的 大 多 数 移动 运营 商 将 把 HSPA+ 和 LTE 作为 未 来 的 移动 无 线 标 
准 。 不 用 紧张 ， 这 应 该 是 件 好 事 。 现 有 的 2G 和 3~3.75G 技术 仍然 是 当前 移动 无 线 
网 络 的 主体 ， 更 重要 的 ， 它 们 至 少 还 会 继续 为 我 们 服务 10 年 。 














3G 经 常 被 称 为 “手机 宽带 "。 但 是 ， 宽 带 是 一 个 相对 的 概念 。 有 人 认为 宽 

心 。 带 至 少 意味 着 256 Kbits 的 速率 ， 也 有 人 认为 宽带 速率 应 该 在 640 Kbit/s 

尾 ， 以 上 。 而 事实 上 ， 这 个 速率 会 因 我 们 的 上 网 应 用 而 有 所 不 同 。 随 着 服务 水 
平 的 提高 ， 以 及 人 们 对 高 速率 需求 的 增长 ， 宽 带 的 速率 也 会 进一步 提高 。 
考虑 到 这 一 点 ， 不 如 把 3G 的 速率 想象 成 达到 甚至 超过 Mbits 级 别 。 超 过 
Mbits 级 别 多 少 ? 那 就 要 看 相应 的 标准 版 本 (如 前 所 述 )、 运 营 商 的 网 络 配 
置 ， 以 及 设备 的 能 力 了 。 





7.1.4 IMT-Advanced 的 4G 要 求 

在 介绍 各 种 4G 技术 之 前 ， 有 必要 先 了 解 一 下 “4G” 这 个 标签 背后 有 什么 。 与 3G 
类 似 ， 也 没有 孤立 的 4G 技术 。 所 谓 4G， 背 后 是 一 组 具体 要 求 (IMT-Advanced ) ， 
这 组 要 求 是 ITU 在 2008 年 就 制定 和 公布 了 的 。 任 何 达到 这 些 要 求 的 技术 ， 都 可 以 
看 作 是 4G 技术 。 


IMT-Advanced 的 部 分 要 求 举例 如 下 : 


。 以 卫 分 组 交换 网 络 为 基础 ; 

。 与 之 前 的 无 线 标准 (3G 和 2G) 兼容 ; 

。 移动 客户 端的 速率 达到 100 Mbit/s， 静 止 时 的 速率 达到 Gbit/s 以 上 ， 
。 100 ms 控制 面 延迟 ，10 ms 用 户 面 延 迟 ; 

。 资源 在 用 户 间 动 态 分 配 和 共享 ; 

。 可 变 带 宽 分 配 ，5~20 Mhz。 








人 


实际 的 要 求 比 这些 多 得 多 ， 但 这 里 的 几 个 要 求 切中 了 我 们 这 里 讨论 的 主题 : 与 前 一 
代 相 比 ， 拥 有 更 高 的 否 吐 量 和 更 低 的 延迟 时 间 。 知 道 了 这 些 条 件 ， 就 该 知道 怎么 划 
分 4G 网 络 了 ， 对 吧 ? 不 能 这 么 说 ， 这 也 太 人 简单 了 ! 营销 部 门 肯 定 会 有 不 同 的 说 法 。 


LTE-Advanced 作为 一 个 标准 ， 是 专门 为 满足 IMT-Advanced 的 所 有 条 件 而 制定 的 。 
事实 上 ， 它 也 是 3GPP 为 此 而 制定 的 第 一 个 标准 。 不 过 ,假如 你 前 面 认真 阅读 了 ， 
那 应 该 会 注意 到 LTE (第 8 个 版 本 ) 和 LTE-Advanced (第 10 个 版 本 ) 是 两 个 不 同 
的 标准 。 从 技术 角度 讲 ，LTE 实际 应 该 算是 3.9G 过 湾 性 标准 ， 尽 管 它 的 很 多 方面 
都 达到 了 4G 的 要 求 ， 但 还 是 不 够 全 面 ! 


不 过 ， 这 正好 是 市 场 营销 人 员 大 显 身手 的 地 方 。ITU 拥有 3G 和 4G 注册 商标 ， 
此 其 用 途 应 该 与 每 一 代 标 准 的 要 求 吻合 。 但 运营 商 在 市 场 营 销 方面 技 高 一 筹 ， 他 们 
把 “4G” 商 标 包装 成 了 包含 一 组 几乎 满足 4G 要 求 的 技术 。 为 此 ，LTE (第 8 个 版 
本 ) 和 大 多 数 HSPA+ 网 络 虽 然 没 有 完全 达到 4G 的 要 求 ， 也 都 被 作为 4G 技术 来 宣 
传 炒 作 。 
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那 到 底 有 设 有 真正 的 4G 技术 呢 ?” 正 在 部 署 之 中 。 但 考虑 到 其 前 儿 代 技术 在 市 场 上 
被 炒 出 了 别 样 的 滋味 ， 我 们 有 必要 提高 警惕 。 无 论 如 何 ,“4G” 这 个 词 儿 如 今 在 很 
多 运营 商 那 里 都 是 含 含糊 糊 的 。 要 知道 真相 ， 你 得 认真 看 那些 小 字 印 刷 的 细则 以 理 
解 这 一 技术 。 








7.1.5 长 期 演进 (LTE) 
尽管 3G 标准 在 不 断 演 进 ， 但 随 着 对 高 速率 和 低 延 迟 的 需求 越 来 越 强 烈 ，UMTS 技 
术 设 计 上 的 内 在 局 限 性 也 暴露 出 来 了 。 为 弥补 这 些 缺 陷 ，3GPP 计划 重新 设计 核心 
及 无 线 网 络 ， 于 是 LTE (Long Term Evolution， 长 期 演进 ) 标准 应 运 而 生 。LTE 与 
前 代 标 准 的 主要 区 别 和 特点 如 下 : 








。 核心 网 络 全 部 为 IP 分 组 交换 网 ， 

。 简化 了 网 络 架 构 ， 降 低 建 设 成 本 ， 

。 用 户 面 和 控制 面 的 低 延 迟 时 间 (分 别 为 <10 ms 和 <100 ms)，; 
。 新 无 线 接 口 及 调制 算法 实现 了 高 吞吐 量 (100 Mbit/s) ; 

。 可 用 于 较 大 的 带宽 配置 及 运营 商 集群 ， 

。 要 求 所 有 设备 支持 MIMO。 


毫 不 奇怪 ， 这 些 特点 与 前 面 介 绍 的 IMT-Advanced 要 求 很 类 似 。LTE (第 8 次 发 布 ) 
商定 了 新 网 络 架 构 的 基础 ， 而 LTE-Advanced (第 10 次 发 布 ) 通过 全 方位 的 改进 达 
到 了 4G 的 要 求 。 


不 过 有 一 点 必须 说 明 ， 由 于 其 无 线 及 核心 网 络 的 实现 的 差异 ，LTE 网 络 可 不 是 对 
已 有 3G 基础 设备 的 简单 升级 。 相 反 ，LTE 网 络 必 须 与 现 有 3G 基础 设备 并 行 部 署 ， 
并 采用 不 同 的 频率 范围 。 不 过 ， 由 于 LTE 是 UMTS 和 CDMA 的 共同 后 继 版 本 ， 因 
此 它 也 提供 了 一 种 兼容 二 者 的 机 制 。 由 此 ，LTE 用 户 可 以 无 颖 切换 到 3G 网 络 ， 并 
在 LTE 基础 设施 就 绪 后 再 迁移 过 来 。 


最 后 ， 顾 名 思 义 ，LTE 的 确 是 一 个 针对 所 有 未 来 移动 网 络 的 长 期 演进 规划 。 唯 一 的 
问题 是 这 个 未 来 有 多 远 ? 有 的 运营 商 已 经 开始 投资 建设 LTE 基础 设备 ， 其 他 运营 商 
也 开始 寻找 频谱 、 资 金 。 不 过 ， 根 据 业 内 人 士 估算 ， 这 次 迁移 肯定 需要 一 个 较 长 的 
周期 ， 或 许 得 需要 十 年 左右 。 在 此 期 间 ，HSPA+ 将 扮演 主角 。 


























所 有 支持 LTE 的 设备 必须 支持 多 射频 ， 以 满足 MIMO 的 要 求 。 可 是 ， 每 

心 。 个 设备 还 需要 单独 的 无 线 接口 以 兼容 早期 的 3G 和 2G 网 络 。 这 样 算 下 来 ， 

性 ， 每 台 设备 至 少 要 支持 3~4 个 射频 ! 为 了 实现 LTE 的 高 速率 ， 甚 至 需要 4x 

MIMO ， 从 而 使 射频 总 数 达 到 5~6 个 。 你 是 不 是 奇怪 过 自己 的 电池 为 什么 
那么 不 抗 用 ? 
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7.1.6 HSPA+ 推 进 世 界 范围 内 的 4G 普 及 

HSPA+ 是 3GPP 在 第 7 次 发 布 时 引入 的 ， 那 是 2007 年 。 不 过 ， 尽 管 人 们 的 眼球 多 
被 3GPP 于 2008 年 第 8 次 发 布 的 LTE 所 吸引 ， 但 不 可 忽视 HSPA+ 始终 没有 停止 改 
进 的 步伐 ,仍然 继续 向 前 发 展 。 事 实 上 ，HSPA+ 的 第 10 次 发 布 已 经 在 很 多 方面 达 
到 了 IMT-Advanced 的 标准 1 


不 过 ， 你 可 能 会 问 ， 如 果 大 家 都 认同 LTE 是 未 来 移动 网 络 的 标准 ， 那 为 什么 还 要 继 
续 改进 和 在 HSPA+ 上 投入 呢 ? 答案 很 简单 : 成 本 。3GPP 的 3G 技术 占据 了 全 球 无 线 
市 场 的 大 部 分 份额 ， 也 就 是 说 ， 世 界 各 地 的 运营 商 在 这 方面 已 经 投入 了 巨 资 。 迁 移 到 
LTE 必须 建设 全 新 的 无 线 网 络 ， 而 这 又 需要 一 大 笔 开 支 。 相 对 而 言 ，HSPA+ 的 投入 
产 出 比 更 可 取 ， 运 营 商 可 以 递增 地 升级 现 有 网 络 ， 同 时 获得 相对 不 错 的 性 能 ! 


投入 产 出 是 运营 商 的 生命 线 ， 也 是 为 什么 业界 预测 (图 7-2) 未 来 几 年 全 球 HSPA+ 
是 向 4G 迁移 的 主体 的 原因 。 在 此 期 间 ，3GPP2 的 CDMA 技术 还 将 继续 存在 ,但 据 
预测 其 用 户 数量 将 缓慢 减少 ， 而 新 的 LTE 网 络 在 不 同 地 区 将 同步 建设 (速率 可 能 不 
同 )。 这 部 分 是 因为 成 本 ， 部 分 是 因为 管制 和 必要 无 线 电 频谱 的 可 用 性 。 
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图 7-2: 北美 4G: HSPA+ 和 LTE 移动 宽带 增长 趋势 


由 于 种 种 原因 ， 北 美 地 区 的 LTE 建设 似乎 处 于 领先 地 位 。 目 前 的 行业 预测 显示 ， 到 
2016 年 ， 美 国 和 加 拿 大 的 LTE 用 户 将 超过 HSPA 用 户 (图 7-3)。 不 过 ， 北 美的 
LTE 部 署 速度 明显 比 其 他 国家 快 很 多 。 从 全 球 来 年 ，HSPA+ 仍然 是 接 下 十 年 中 主导 
的 移动 无 线 技术 。 


国 HSPA+ 国 LTE 
0 
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7-3: 北美 4G: 美国 及 加 拿 大 HSPA+ 和 LTE 增长 趋势 
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虽然 很 多 人 看 到 HSPA+ 与 LTE 趋势 对 比 会 感到 惊讶 ， 但 这 个 结果 其 实 并 
4 4 、 不 意外 。 抛 开 其 他 因素 不 提 ， 这 个 趋势 至 少 能 反映 一 个 事实 ， 即 一 个 新 的 
径 ， 无 线 标准 要 在 现实 中 成 为 主流 技术 ， 大 概要 花 10 年 时 间 。 
放眼 未 来 ， 应 该 说 到 2020 年 代 早 期 LTE-Advanced 成 为 主流 不 是 梦 | 遗憾 
的 是 ， 新 无 线 基础 设施 的 建设 总 是 那么 烧 钱 、 费 时 。 








7.1.7 为 多 代 并 存 的 未 来 规划 
通信 行业 是 容 不 得 半点 主观 腾 断 的 。 但 到 目前 为 止 ， 我 们 已 经 介绍 了 足够 的 背景 
应 该 能 够 就 未 来 的 移动 网 络 和 先进 程度 作出 合理 的 预期 。 


首先 ， 无 线 标准 发 展 很 快 ， 但 这 些 网 络 的 物理 设施 建设 则 既 要 花 钱 又 得 花 时 间 。 将 
来 ， 如 果 这 些 网 络 部 署 完成 ， 那 势必 还 要 投入 很 多 时 间 维 护 以 收回 成 本 ， 保 证 服务 
品质 。 换 句 话说， 尽管 市 场 上 对 4G 的 宣传 炒作 沸沸扬扬 ， 老 一 代 网 络 至 少 还 得 服 
务 社会 十 年 以 上 。 所 以 ， 在 创建 移动 Web 应 用 时 ， 应 该 考虑 这 一 点 。 








让 人 觉得 讽刺 的 是 ， 虽 然 4G 网 络 在 卫 数据 传输 方面 的 性 能 有 了 很 大 提 
升 ， 但 3G 网 络 在 处 理 老 式 语音 通信 方面 反而 更 有 效率 ! VoLTE (Voice 
:over LTE) 正在 积极 制定 ， 目 标 是 通过 4G 网 络 高 效 可 靠 地 传输 语音 。 但 
目前 ， 大 多 数 4G 网 络 仍然 要 靠 原来 的 电路 交换 设备 传输 语音 。 




















自然 地 ， 在 面向 移动 网 络 构 建 应 用 时 ， 不 能 只 考虑 一 种 网 络 ， 更 不 能 寄 希 望 于 特定 
的 吞吐 量 或 延迟 时 间 。 前 面 已 经 介绍 过 ， 任 何 网 络 的 实际 性 能 都 具有 高 度 可 变性 ， 
取决 于 部 署 的 版 本 、 基 础 设施 、 无 线条 件 ， 以 及 其 他 众多 的 因素 。 我 们 的 应 用 要 能 
适应 不 断 变化 的 条 件 ， 吞 吐 量 、 延 迟 时 间 ， 甚 至 无 线 连接 的 有 无 ， 都 可 能 变化 。 如 
果 用 户 正 移动 着 ， 那 么 很 可 能 要 跨越 儿 代 不 同 的 网 络 (LTE、HSPA+、HSPA、EV- 
DO， 甚 至 GPRS Edge)， 具 体 就 要 看 信号 强度 和 和 覆盖 范围 了 。 如 果 你 的 应 用 没有 劳 
虑 这 一 点 ， 用 户 体验 就 会 下 降 。 


好 在 ，HSPA+ 和 LTE 的 采用 速度 很 快 ， 这 样 那些 依赖 高 吞吐 量 和 低 延 迟 时 间 的 应 
用 就 可 以 脱颖而出 。 这 两 种 新 标准 的 吞吐 量 和 延迟 时 间 指 标 是 很 惊人 的 ( 表 7-6) : 
现实 中 的 吞吐 量 能 达到 一 位 数 Mbits 的 中 高 级 别 ， 延 迟 时 间 则 低 于 100 ms。 这 两 个 
指标 已 经 堪 比 很 多 家 庭 和 办 公 室 的 Wi-Fi 网 络 了 。 


不 过 ， 尽 管 4G 无 线性 能 经 常 可 以 媲美 Wi-Fi， 甚 至 有 线 网 络 ， 但 将 它们 等 同 视 之 则 
是 不 应 该 的 ， 不 ， 应 该 说 是 绝对 不 可 以 的 。 




















表 7-6: HSPA+、LTE 及 LTE-Advanced 的 对 比 








HSPA+ ilE LTE-Advanced 
下 载 峰值 (Mbit/s) 168 300 3000 
上 传 峰值 (Mbit/s) 22 75 1500 
最 大 MIMO 流 2 4 8 
空闲 到 连接 的 延迟 (ms) < 100 < 100 <50 
休眠 到 活动 的 延迟 (ms) <50 <50 <10 
] 户 面 单 向 延迟 (ms) <10 <5 < 

















比如 说 ， 大 多 数 用 户 和 开发 人 员 都 期 待 “一 直 在 线 ” 的 体验 ， 即 设备 始终 连接 着 互 
联网 ， 随 时 可 以 响应 用 户 输入 或 到 来 的 数据 。 这 种 期 待 在 无 线 网 络 环 境 没 有 什么 问 
题 ， 但 对 无 线 网 络 而 言 绝 对 是 不 现实 的 。 电 凶 容 量 和 设备 能 力 等 现实 因素 ， 让 我 们 
不 得 不 明确 考虑 移动 网 络 的 局 限 性 。 为 了 加 深 理解 ， 让 我 们 再 进一步 。 











用 户 面 单 向 延迟 
用 户 面 单 向 延迟 是 LTE 标准 规定 的 一 个 目标 时 间 ， 指 的 是 一 个 分 组 在 无 线 设备 与 
无 线 发 射 塔 之 间 单 向 传输 的 时 间 。 换 向 话说 ， 就 是 设备 处 于 大 功 府 连续 接收 状态 
时 ， 第 一 跳 的 延迟 时 间 。 任 何 应 用 的 数据 传输 都 必须 付出 这 个 代价 ， 没 有 捷径 。 


7.2 设备 特性 及 能 

经 常 被 人 忘记 的 一 个 事实 ， 就 是 现 有 无 线 网 络 只 是 问题 的 一 半 。 另 一 半 当 然 是 来 自 
不 同 厂商 的 设备 ， 以 及 它们 的 上 市 时 间 ， 这 些 设 备 备 有 各 的 特点 。 比 如 ，CPU 速度 
和 核心 数量 、 内 存 大 小 、 存 储 能 力 、 有 无 GPU 等 。 这 些 因素 中 的 任何 一 个 都 会 影响 
设备 以 及 运行 于 其 上 的 应 用 的 整体 性 能 。 


不 过 ， 即 使 考虑 到 了 上 述 所 有 因素 ， 对 于 网 络 性 能 而 言 ， 还 是 有 一 个 经 常 被 忽视 的 
方面 :无线 电 收 发 能 力 。 特 别 地 ， 用 户 手 里 拿 着 的 设备 必须 能 利用 无 线 基础 设施 | 
运营 商 可 能 会 部 署 最 新 的 LTE 网 络 ， 但 上 市 较 早 的 设备 可 能 根本 就 不 支持 该 网 络 ， 
反之 亦 然 。 


用 户 设备 分 类 

3GPP 和 3GPP2 标准 都 在 持续 演进 ， 不 断 提高 对 无 线 接口 的 要 求 ， 包 括 调制 方法 、 
射频 数量 ， 等 等 。 为 了 获得 最 佳 性 能 ， 设 备 必须 达到 每 种 网 络 对 特定 UE (User 
Equipment， 用 户 设备 ) 类 别 的 要 求 。 事 实 上 ， 每 次 发 布 标准 的 新 版 本 时 ， 经 常会 

多 个 UE 类 别 ， 每 个 类 别 分 别 对 应 着 不 同 的 无 线性 能 。 
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明显 但 又 十 分 重要 的 一 个 问题 就 是 ， 为 什么 ? 跟 往 常 一 样 ， 答 案 很 简单 : 成 本 。 多 
个 设备 类 别 就 是 认可 设备 的 差异 化 ， 它 们 的 价格 可 以 不 同 ， 以 适应 不 同 的 收入 水 平 
的 用 户 ， 它 们 的 能 力 可 以 不 同 ， 以 适应 当前 部 署 的 不 同 的 网 络 。 























单单 HSPA 标准 就 规定 了 36 个 可 能 的 UE 类 别 ! 事实 上 ， 你 说 自己 有 一 个 “支持 
HSPA 的 设备 ”( 表 7-7) ， 这 和 句 话 还 是 不 够 确切 。 比 如 ， 假 设 无 线 网 络 可 用 ， 那 要 获 
得 42.2 Mbit/s 的 吞吐 量 ， 必 须 有 一 个 类 别 20 (2x MIMO) 或 类 别 24 ( 双 小 区 ) 的 
设备 。 更 麻烦 的 是 ， 类 别 21 的 设备 (23.4 Mbits 的 峰值 速率 ) 并 不 保证 会 比 类 别 
20 的 设备 具有 更 高 的 吞吐 量 。 


表 7-7: 3GPP HSPA UE 类 别 示例 





3GPP 版 本 类 别 MIMO， 多 小 区 峰值 速率 ( Mbit/s ) 
5 8 一 7.2 

5 10 会 14.0 

7 14 一 21.1 

8 20 2x MIMO 42.2 

8 21 双 小 区 23.4 

8 24 双 小 区 42.2 

10 32 四 小 区 + MIMO 168.8 

















类 似 地 ，LTE 标准 也 定义 了 自己 的 UE 类 别 〈 表 7-8) : 高 端的 智能 手机 一 般 是 类 别 
3~5 的 设备 ， 但 它 也 有 可 能 与 类 别 1~2 中 更 廉价 的 设备 共享 网 络 。UE 类 别 编号 越 
大 ， 比 如 要 求 4x 或 gx MIMO， 越 有 可 能 是 专用 设备 。 但 多 路 无 线 信号 同时 发 射 也 
会 消耗 更 多 电量 ， 对 一 般 用 户 来 讲 恐 怕 并 不 实用 。 


表 7-8: LTE UE 类 别 








3GPP 版 本 类 别 MIMO 峰值 下 载 速率 ( Mbit/s ) 峰值 上 传 速率 ( Mbit/s ) 
8 1 1x 10.3 5.2 

8 2 2x 51.0 25.5 

8 3 2x 102.0 51.0 

8 4 2x 150.8 51.0 

8 5 4x 299.6 75.4 

10 6 2x 或 4x 301.5 51.0 

10 7 2x 或 4x 301.5 102.0 

10 8 8x 2998.6 1497.8 














现实 中 ， 大 多 数 早期 LTE 网 络 都 面向 类 别 1~3 的 设备 ， 而 早期 LTE- 
We @ « Advanced 网 络 则 主要 将 类 别 3 作为 主要 的 UE 类 别 。 








如 果 你 有 一 台 LTE 或 HSPA+ 设备 ， 那 你 知道 它 属于 哪个 类 别 吗 ? 知道 了 所 属 类 别 
之 后 ， 那 你 知道 网 络 运 营 商 正在 运行 的 是 3GPP 发 布 的 哪个 版 本 吗 ? 要 想 获 得 最 佳 
性 能 ， 这 两 方面 必须 匹配 。 否 则 ， 无 线 网 络 或 手机 中 的 一 方 就 会 成 为 瓶颈 。 











移动 设备 的 无 线 电 规范 解密 
如 果 你 看 过 自己 移动 设备 的 技术 规格 ， 那 “无 线 与 蜂 帘 网络” 部 分 罗列 的 大 量 频 
率 和 技术 一 定 会 让 你 头晕 眼花。 不 过 ， 有 了 之 前 的 介绍 ， 解 密 这 些 频 率 和 技术 应 
该 就 不 难 了 。 举 个 例子 吧 ， 我 们 看 一 看 谷歌 Nexus 4 的 技术 规格 : 
。 GSM/EDGE/GPRS (850、900、1800、1900 MHz) 
。 3G (850、900、1700、1900、2100 MHz) 
。 HSPA+ 42 


第 一 行 告 诉 我 们 这 人 台 设 备 可 以 在 2G 网 络 中 运行 ， 而 且 支 持 GPRS (2.5G) 和 
EDGE (2.75G)， 峰值 速率 可 达 几 百 Kbit/s。 列 出 的 频 举 表 示 可 以 收发 的 无 线 电 频 
谱 ， 以 适应 不 同 地 区 的 频谱 管制 及 网 络 部 署 情况 。 

第 二 行 也 类 似 ， 只 不 过 没有 标示 出 最 大 的 3G 吞吐 量 。 不 过 ， 第 三 行 揭 示 了 这 个 
信息 : HSPA+ 表示 这 部 手机 可 以 在 3.75G 网 络 中 运行 ， 数字“42” 的 意思 是 该 设 
备 要 么 属于 支持 MIMO 的 类 别 20， 要 么 属于 支持 双 小 区 的 类 别 24， 最 高 下 行 速 
率 可 达 42.2 Mbits (当然 是 在 网 络 允许 的 条 件 下 )。 事 实 上 ，Nexus 4 是 一 部 类 别 
24 的 双 小 区 设备 。 

最 后 ， 我 们 知道 这 部 手机 不 支持 LITE， 要 支持 LTE 就 需要 除 2G、3G 之 外 的 另 一 
套 无 线 接口 。 在 很 多 手机 都 已 经 做 得 非常 小 巧 的 条 件 下 ， 居 然 还 能 同时 内 置 多 套 
无 线 电 收发 装置 (大 多 数 内 置 有 2~4 套 )， 简 直 叹 为 观 止 | 











7.3 无 线 电 资源 控制 器 (RRC) 


3G 和 4G 网 络 都 有 一 个 独特 的 装置 ， 这 个 装置 在 有 线 网 甚至 Wi-Fi 中 都 是 不 存在 
的 。 这 个 装置 就 是 无 线 电 资源 控制 器 (RRC，Radio Resource Controller ) 。RRC 负 
责 调度 协调 移动 设备 与 无 线 电 基站 之 间 所 有 的 通信 连接 (图 7-4)。 理 解 为 什么 要 有 
这 么 一 个 装置 ， 以 及 它 对 移动 网 络 的 性 能 有 什么 影响 关系 到 能 否 构建 高 性 能 的 移动 
应 用 。RRC 直接 影响 延迟 、 吞 吐 量 和 设备 电 字 的 使 用 时 间 。 
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WAN 














7-4: 无 线 电 资 源 控 制 器 


使 用 物理 连接 方式 ， 比 如 以 太 网 线 连接 时 ， 计 算 机 直接 连接 网 络 并 且 始 终 在 线 ， 因 
此 连接 两 端 可 以 随时 发 送 数据 。 在 这 种 情况 下 ， 延 迟 时 间 才 可 能 降 到 最 得。 就 如 6.1 
节 “ 从 以 太 网 到 无 线 局 域 网 ”所 述 ，Wi-Fi 标准 的 连接 方式 也 是 类 似 的 ， 即 联网 的 
设备 之 间 可 以 随时 通信 。 这 种 情况 下 ， 延 迟 时 间 也 有 可 能 降 到 最 低 ， 但 由 于 设备 共 
享 无 线 电 介质 ， 如 果 活 动用 户 很 多 ， 那 么 也 会 导致 冲突 和 较 大 的 性 能 变化 。 另 外 ， 
由 于 Wi-Fi 网 络 中 的 任何 一 端 随 时 可 以 发 送 数据 ， 那 其 他 设备 必须 随时 做 好 接收 数 
据 的 准备 ， 因 此 无 线 电 收发 必须 始终 开启 ， 从 而 消耗 很 大 电量 。 


实践 中 ， 保 持 Wi-Fi 无 线 信号 不 间断 代价 太 大 ， 因 为 大 多 数 设备 的 电池 容量 都 有 限 。 
为 此 ，Wi-Fi 标准 也 有 一 个 优化 策略 ， 即 无 线 接 和 点 在 向 某 个 客户 端 发 送 数据 之 前 ， 
会 先 通过 一 个 周期 性 的 信号 帧 广播 DTIM (Delivery Traffic Indication Message， 发 
送 数据 指示 消息 )。 相 应 地 ， 客 户 端 会 收听 这 些 DTIM 帧 ， 以 便 做 好 接收 数据 的 准 
备 。 其 他 时 间 ， 无 线 电 装置 可 以 处 于 休眠 状态 。 这 个 优化 策略 省 了 电 ， 却 增加 了 延 
迟 时 间 。 














未 来 的 WMM (Wi-Fi Multimedia，Wi-Fi 多 媒体 ) 标准 会 进一步 提升 
心 。Wi-Fi 设备 的 电源 使 用 效率 ， 主 要 是 会 采用 新 的 PowerSave 机 制 ， 比 如 
4, NoAck 和 APSD (Automatic Power Save Delivery， 自 动 省 电 传输 )。 





3G 和 4G 网络 也 存在 同样 的 问题 : 平衡 网 络 传输 效率 与 电源 使 用 效率 。 换 句 话 说， 
移动 设备 受 限于 电池 容量 ， 经 常会 电源 告急 ， 而 一 个 小 区 内 的 活跃 用 户 又 都 希望 网 
络 效率 较 高 ， 这 就 产生 了 矛盾 。 于 是 ，RRC 出 现 了 。 
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顾名思义 ， 无 线 电 资源 控制 器 全 权 负 责 谁 在 什么 时 候 能 发 言 ， 带 宽 多 大 ， 功 率 多 少 ， 
以 及 监控 每 个 设备 的 电源 状态 等 。 简 而 言 之 ，RRC 就 是 无 线 电 网 络 的 大 脑 。 想 要 通 
过 无 线 信道 发 送 数据 ? 你 必须 先 向 RRC 申请 无 线 电 资 源 。 想 要 接收 互联 网 上 的 数 
据 ? RRC 会 通知 你 什么 时 候 监 听 接 收 到 来 的 分 组 。 


好 消息 是 ，RRC 管理 全 都 由 网 络 负 责 。 坏 消息 是 ， 你 不 能 通过 API 适当 地 控制 
RRC， 假 如 想 针对 3G 或 4G 网络 优 化 自己 的 应 用 ， 那 就 得 知道 并 在 RRC 的 限制 之 
内 操作 。 























RRC 存在 于 无 线 电网 络 中 。2G 和 3G 网 络 中 的 RRC 处 于 核心 运营 网 络 ， 
人 Q 4、 而 在 4G 中 ， 为 提升 性 能 、 减 少 协调 时 间 ，RRC 被 转移 到 了 无 线 信号 塔 
人 (eNodeB ) 。 





7.3.1 3G、4G 和 Wi-Fi 对 电源 的 要 求 

无 线 电 在 任何 手持 设备 中 都 是 最 耗 电 的 组 件 之 一 。 要 说 最 耗 电 ， 当 然 是 点 亮 的 屏幕 
了 ， 注 意 是 点 亮 时 的 屏幕 。 但 在 实际 使 用 中 ， 屏 幕 一 般 情 况 下 都 是 熄灭 的 ， 反 倒是 
无 线 电 组 件 ， 为 了 让 用 户 有 “永远 在 线 ” 的 体验 ， 必 须 一 直 运 行 。 


实现 这 个 目标 的 一 种 方式 就 是 让 无 线 电 组 件 不 停 地 工作 ， 可 即使 是 当今 最 大 容量 的 电 
池 ， 这 么 干 也 会 在 几 小 时 内 把 电量 耗 尽 。 况 且 ，3G 和 4G 的 最 新 版 本 要 求 并 行 传输 
(MIMO、 多 小 区 ， 等 等 )， 这 相当 于 同时 开局 了 多 个 无 线 电 组 件 。 实 践 中 ， 必 须 在 保 
持 无 线 电 开局 以 降低 通信 延迟 ， 与 保持 低 电 量 消耗 以 延长 待机 时 间 之 间 取 得 平衡 。 


不 同 的 技术 有 什么 不 同 ， 哪 一 种 更 有 利于 延长 电 字 寿命 ? 答案 不 一 而 足 。 在 Wi-Fi 网 
络 中 ， 每 个 设备 自己 设 定 传输 功率 ， 通 常 是 30~200 mW。 不 同 的 是 ，3G/4G 无 线 发 
射 功 率 是 由 网 络 说 了 算 ， 空 闲 状 态 下 最 低 为 13 mW。 然 而 ， 考 虑 到 要 覆盖 更 大 范围 
以 及 排除 干扰 ， 这 两 个 网 络 在 通信 时 要 求 的 最 高 功率 会 达到 1000~3500 mW ! 


实践 中 ， 在 传输 大 量 数据 时 ， 如 果 信 号 强度 足够 大 ，Wi-Fi 通常 效率 更 高 。 不 过 ， 
如 果 设 备 经 常 空间 ， 则 3G/4G 网 络 的 效率 更 高 。 要 获得 最 佳 性 能 ， 最 理想 的 做 法 就 
是 能 够 在 不 同类 型 的 连接 之 间 动 态 切换 。 然 而 ， 至 少 目前 来 看 ， 还 没有 这 人 么 一 种 机 
制 。 但 这 个 领域 的 研究 十 分 活跃 ， 产 业界 和 学 术 界 都 非常 积极 。 


好 了 ， 电 字 和 功率 管理 到 底 怎么 影响 性 能 呢 ? “信号 功率 ”是 达成 高 吞吐 量 的 一 个 
主要 手段 。 然 而 ， 信 号 功率 越 高 ， 消 耗 的 能 量 也 会 显著 增多 ， 因 而 是 可 以 对 其 加 以 
市 流 ， 以 期 延长 电池 寿命 的 。 同 样 ， 停 止 无 线 电 信号 发 射 也 可 能 会 断 开设 备 与 发 
射 塔 之 间 的 数据 信道 。 而 这 就 意味 着 每 次 数据 传输 之 前 ， 都 必须 经 过 一 番 控制 信息 
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的 交换 ， 从 而 导致 儿 十 甚至 儿 百 ms 的 网 络 延 迟 。 


吞吐 量 和 延迟 时 间 都 与 设备 的 功率 管理 策略 直接 相关 。 事 实 上 ，3G 和 4G 网络 中 的 
ee 告诉 你 什么 时 候 开 始 通 
信 ， 还 会 告诉 你 发 射 功 率 多 大 ， 以 及 什么 时 候 切 换 到 另 一 种 功率 。 


7.3.2 LTE RRC 状 态 机 


ee 事实 上 ， 
3GPP 标准 定义 了 一 个 完备 的 状态 机 ， 这 个 状态 机 描述 了 连接 到 网 络 的 每 个 设备 的 
ye 以 触发 状态 切换 ， 而 状态 机 
自身 则 对 所 有 LTE 基础 设施 和 设备 一 视 同 仁 。 








RRC 空 朵 RRC 已 连接 





司 一 > 数据 传输 
| 一 > 超时 











----F------------------r---|----. 
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7-5 LTE RRC 状态 机 


。 RRC 空 闲 
设备 的 无 线 电 模块 处 于 低 功率 状态 (<15 mW)， 只 监听 来 自 网 络 的 控制 信号 。 运 
营 商 网 络 中 的 客户 端 没有 无 线 电 资源 。 


。 RRC 连 接 
设备 的 无 线 电 模块 处 于 高 功率 状态 (1000~3500 mW)， 要 么 传输 数据 ， 要 么 等 待 
数据 。 运 营 商 网 络 中 指定 了 数据 承载 方式 ， 也 分 配 了 专用 的 无 线 电 资 源 。 


简单 来 说 ， 设 备 要 么 处 于 空闲 状态 ， 要 么 处 于 连接 状态 。 处 于 空闲 状态 时 ， 设 备 只 
监听 控制 信道 的 广播 ， 比如 准备 接收 数据 的 通 知 ; 处 于 连接 状态 时 ， 网 络 通信 环境 
就 绪 ， 相 应 资源 也 将 分 配给 客户 端 。 


于 空 困 状态 时 ， 设 备 不 能 发 送 或 接收 任何 数据 。 要 收发 数据 ， 设 备 必须 先 通过 监 














听 网 络 让 自己 与 网 络 同步 ， 然 后 再 向 RRC 发 送 一 个 将 其 切换 到 “已 连接 ”状态 的 请 
求 。 这 个 协商 过 程 可 能 需要 几 次 往返 ，3GPP LTE 规范 对 这 个 状态 切换 的 容许 条 件 
是 小 于 等 于 100 ms。 在 LTE-Advanced 中 ， 这 个 切换 时 间 进 一 步 缩短 为 50 ms。 


切换 到 连接 状态 后 ， 无 线 信 号 塔 与 LTE 设备 之 间 的 网 络 环境 准备 就 结 ， 随 时 可 以 传 
输 数据 。 然 而 ， 如 果 通 信 的 一 方 结束 了 数据 传输 ， 那 RRC 怎么 知道 什么 时 候 把 设备 
切换 到 低 功率 状态 呢 ? 这 个 问题 癌 到 点 子 上 了 ， 答 案 是 不 会 ! 


IP 通信 具有 突 发 性 ， 优 化 的 TCP 连接 是 持久 的 ， 而 UDP 通信 就 没有 设计 提供 “ 传 
输 结 束 ” 指 示 。 结 果 ， 与 3.2.1 节 介 绍 的 NAT 不 同 ，RRC 状态 机 依赖 于 一 组 计时 器 
来 触发 RRC 的 状态 切换 。 


最 后 ， 由 于 连接 状态 需要 的 功率 很 高 ， 为 了 更 有 效 地 完成 操作 ， 就 有 了 多 个 子 状 态 
(图 7-5) 。 


。 连续 接收 
最 高 功率 状态 ， 网 络 环境 就 绪 ， 已 分 配 网 络 资源 。 


。 短 不 连续 接收 ( 短 DRX) 
网 络 环境 就 绪 ， 未 分 配 网 络 资源 。 


。 长 不 连续 接收 (长 DRX) 
网 络 环境 就 绕 ， 未 分 配 网 络 资源 。 


在 高 功率 状态 下 ，RRC 为 设备 保留 信道 以 接收 和 发 送 数据 ， 然 后 将 时 隙 、 发 射 功 
率 、 调 制 模式 等 十 余 个 参数 通知 设备 。 此 时 ， 如 果 设 备 空闲 时 间 已 经 达到 了 配置 的 
时 间 ， 则 切换 到 短 DRX 状 态 ， 即 网 络 环境 仍然 保持 ， 但 不 分 配 特 定 的 无 线 电 资源 。 
在 短 DRX 状态 下 ， 设 备 只 会 监听 网 络 周期 性 的 广播 ， 从 而 节省 电能 一 一 与 Wi-Fi 的 
DTIM 间歇 不 同 。 








什么 是 “分 配 的 无 线 电 资源 ” 
与 大 多 数 现代 无 线 标准 一 样 ，LTE 也 共享 上 行 和 下 行 无 线 电 信道 ， 对 这 个 信道 的 
访问 权 由 RRC 控制 。 在 连接 状态 下 ，RRC 告诉 所 有 设备 哪个 时 隙 分 配给 了 谁 ， 
必须 使 用 多 大 的 发 射 功率 、 调 制 方式 ， 以 及 其 他 十 余 个 参数 。 
如 果 移 动 设 备 没有 得 到 RRC 分 配 的 这 些 资源 ， 那 它 就 不 能 发 送 和 接收 任何 用 户 数 
据 。 因 此 ， 在 处 于 DRX 状态 时 ， 设 备 与 RRC 同步 ， 但 还 没有 被 分 配 上 行 或 下 行 
资源 。 此 时 的 设备 处 于 “ 半 醒 ”状态 。 
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如 果 无 线 电 空 闪 了 足够 长 的 时 间 ， 则 设备 切换 到 “长 DRX” 状 态 。 除 了 在 被 唤醒 以 
监听 广播 之 前 要 休眠 更 长 时 间 之 外 ， 长 DRX 与 短 DRX 状态 是 一 样 的 (图 7-6)。 





数据 传输 短 DRX 
长 DRX :…> 活动 间隙 











连接 且 活动 ”| 连接 但 休 限 > 微 胜 腿 间 辽 


发 射 间 隐 











图 7-6: 不 连续 接收 : 短 DRX 与 长 DRX 


如 果 网 络 或 移动 设备 必须 在 无 线 电 处 于 短 DRX 或 长 DRX (休眠 ) 状态 下 传输 数据 ， 
怎么 办 ?设备 和 RRC 必须 先 交 换 控 制 信息 ， 以 协商 何 时 开始 传输 ， 何 时 监听 无 线 
电 广 播 。 对 LTE 而 言 ， 协 商 时 间 (从 休眠 到 连接 ) 规定 为 50 ms 以 内 ， 而 在 LTE- 
Advanced 中 ， 这 个 时 间 将 被 进一步 缩短 为 10 ms。 


这 些 在 实际 当中 都 意味 着 什么 呢 ? 取决 于 实际 的 功率 ，LTE 设备 可 能 要 先 花 10 到 
100 ms 与 RRC 协商 必要 的 资源 ( 表 7-9)， 然 后 才能 通过 无 线 连接 传输 应 用 数据 ， 
通过 运营 商 网 络 ， 再 到 公共 互联 网 。 在 设计 应 用 特别 是 对 延迟 敏感 的 应 用 时 ， 是 否 
考虑 到 了 这 些 延 迟 ， 决 定 了 你 的 应 用 是 真正 经 过 了 优化 ， 还 是 “性 能 不 好 ”。 


表 7-9: LTE 与 LTE-Advanced 中 的 RRC 延 迟 








TiE LTE-Advanced 
空间 到 连接 的 延迟 <100ms <50ms 
DRX 到 连接 的 延迟 <50 ms <10ms 
用 户 面 单 向 延迟 <5ms <5ms 





7.3.3 HSPA 与 HSPA+ CUMTS) RRC 状 态 机 


LTE 及 LTE-Advanced 之 前 的 3GPP 网 络 具 有 类 似 的 RRC 状态 机 ， 而 且 同 样 由 无 线 
电网 络 维持 。 这 是 我 们 喜闻乐见 的 一 方面 。 但 另 一 方面 ， 早 期 网 络 的 状态 机 还 要 更 
复杂 一 些 〈 图 7-7) ， 延 迟 时 间 长 很 多 。 事 实 上， 之 所 以 LTE 的 性 能 更 好 ， 就 是 因为 
它 简 化 了 状态 机 的 架构 ， 从 而 提升 了 状态 切换 的 性 能 








。 空 六 
与 LTE 类 似 。 设 备 的 无 线 电 模块 处 于 低 功 率 状态 ， 只 监听 来 自 网 络 的 控制 信号 
运营 商 网 络 中 的 客户 端 没有 无 线 电 资源 。 
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。 Cell DCH 
连续 接收 时 与 连接 状态 的 LTE 类 似 。 设 备 的 无 线 电 模 块 处 于 高 功率 状态 ， 为 上 
下 行 数据 流 的 传输 分 配 网 络 资 源 。 


。 Cell FACH 
设备 无 线 电 模块 处 于 中 等 功率 状态 ， 比 DCH 状态 消耗 的 电量 少 很 多 。 设 备 没有 
专用 的 网 络 资源 ， 但 能 通过 共享 的 低速 信道 (通常 不 足 20 Kbit/s) 传输 少量 用 户 
数据 。 





一 > 数据 传输 
一 超时 





是 王 东 辟 示 











图 7-7: UMTS RRC 状态 机 : HSPA、HSPA+ 


空间 和 DCH 状态 与 LTE 中 的 空间 和 连接 状态 基本 相同 。 但 是 ， 中 间 的 FACH 状态 
则 是 UMTS 网 络 (HSPA、HSPA+) 所 特有 的 ， 这 个 状态 下 可 以 通过 公用 信道 传输 
少量 数据 一 一 慢 、 稳 定 ， 消 耗 的 电量 只 有 DCH 状态 的 一 半 。 实 践 中 ， 这 种 状态 多 用 
于 处 理 非 交互 通信 ， 比 如 很 多 后 台 应 用 的 轮 询 和 状态 检测 。 














毫 不 意外 ，DCH 到 FACH 状态 的 切换 是 通过 计时 器 实现 的 。 可 是 ，FACH 到 DCH 
的 触发 器 是 什么 ?每 部 设备 都 会 缓存 一 些 要 发 送 的 数据 ， 只 要 数据 量 不 超过 网 络 配 
置 的 国 值 (通常 是 100~1000 字 节 )， 设 备 就 会 一 直 处 于 中 间 状 态 。 而 且 ， 如 有 果 处 于 
FACH 状态 一 定时 间 后 ， 仍 然 没 有 要 传输 的 数据 ， 则 另 一 个 计时 器 就 会 把 设备 切换 
到 空闲 状态 。 














4 ， 只 有 一 个 中 间 状 态 : FACH。 然 而 ， 即 便 从 理论 上 说 ，LTE 能 够 做 到 对 电 
” 量 的 更 优 控制 ， 但 无 线 电 模块 本 身 还 是 会 消耗 LTE 设备 的 电量 。 毕 竞 ， 更 
高 的 吞吐 量 需要 更 多 的 电量 作 支 撑 。 实 际 上 。LTE 设备 的 耗 电量 比 之 前 的 
3G 设备 高 得 多 。 


Ey 与 提供 了 两 个 中 间 状 态 ( 短 DRX 和 长 DRX) 的 LTE 不 同 ， UMTS 设备 
a 

[4 

4 
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除了 不 同 的 功率 状态 之 外 ， 早 期 3G 网 络 与 LTE 的 最 大 区 别 息 怕 就 是 状态 切换 的 延 
迟 了 。LTE 网 络 从 空闲 到 连接 状态 的 延迟 只 有 几 百 ms， 同 样 从 空闲 到 DCH 状态 的 
切换 在 3G 网 络 中 则 需要 多 达 两 秒 ， 而 且 3G 设备 与 RRC 之 间 还 要 交换 几 十 次 控制 
消息 ! FACH 到 DCH 的 切换 也 好 不 到 哪 去 ， 最 长 达 一 秒 半 。 


好 在 ， 最 新 的 HSPA+ 网 络 对 此 做 出 了 重大 改进 ， 已 经 可 以 同 LTE 媲美 了 ( 表 7-6)。 
不 过 ， 我 们 不 能 指望 4G 或 HSPA+ 一 统 天 下 ， 很 多 旧 3G 网 络 仍然 要 继续 存在 至 少 
10 年 。 所 以 ， 任 何 移动 应 用 在 通过 3G 接口 访问 网 络 时 ， 都 要 考虑 由 RRC 导致 的 长 
达 儿 秒 钟 的 延迟 。 


7.3.4 EV-DO (CCDMA) RRC 状 态 机 

尽管 HSPA、HSPA+ 和 LTE 等 3GPP 标准 是 目前 全 球 主流 的 网 络 标准 ， 但 我 们 也 不 
能 忽略 3GPP2 CDMA 网 络 的 存在 。EV-DO 网 络 的 发 展 虽 然 比较 缓慢 ， 但 据 行 业 预 
测 ，2017 年 的 CDMA 用 户 也 将 达到 5 亿 ! 


不 用 说 ， 虽 然 标准 之 间 存 在 差别 ， 但 UMTS 和 CDMA 网 络 的 局 限 性 却 是 共同 的 : 电 
池 电 量 是 约束 条 件 ， 而 无 线 电 模块 非常 耗 电 ;网络 效率 都 需要 提高 。 因 此 ，CDMA 
网 络 同 样 具 有 RRC 状态 机 (图 7-8) ， 用 于 控制 每 部 设备 的 无 线 电 模块 的 状态 。 








一 数据 传输 
一 y 超时 


omen ] 


邱 下 于 辟 孙 











7-8: CDMA RRC 状态 机 : EV-DO (Rev. 0 - DO Advanced) 


。 空闲 
与 3GPP 标准 类 似 。 设 备 的 无 线 电 模块 处 于 低 功 率 状态 ， 只 监听 来 自 网 络 的 控制 
信号 。 运 营 商 网 络 中 的 客户 端 没 有 无 线 电 资源 。 

。 连接 
与 LTE 的 连接 和 HSPA 中 的 DCH 状态 类 似 。 设 备 的 无 线 电 模块 处 于 高 功率 状 
态 ， 为 上 下 行 数 据 流 的 传输 分 配 网 络 资源 。 





106 | 第 7 章 


这 是 我 们 见 过 的 最 简单 的 状态 机 : 设备 要 么 处 于 高 功率 状态 ， 获 得 网 络 资源 ， 要 人 么 
空间 。 任 何 网 络 传输 都 要 切换 到 连接 状态 ， 相 应 的 延迟 时 间 与 HSPA 网 络 差不多 ， 
大 概 有 几 百 或 几 千 ms 〈( 视 基础 设施 的 先进 程度 而 不 同 )。 没 有 中 间 状 态 ， 而 且 向 空 
朵 状态 过 渡 也 由 运营 商 配置 的 超时 时 间 控 制 。 


7.3.5” 低 效率 的 周期 性 传输 

不 管 是 哪 一 代 或 底层 使 用 了 什么 标准 ， 由 超时 时 间 控 制 的 无 线 电 状态 切换 都 会 带 来 
严重 的 后 果 : 你 的 应 用 在 访问 网 络 时 很 容易 既 耗 电 ， 体 验 又 不 顺畅 。 因 为 必须 等 待 
足够 长 的 时 间 ， 才 能 让 无 线 电 模块 切换 到 低 功率 状态 ， 然 后 再 通过 网 络 访问 触发 
RRC 状态 切换 ! 














为 说 明 这 个 问题 ， 假 设 有 一 部 使 用 HSPA+ 网 络 的 设备 ， 该 设备 被 配置 为 在 无 线 电 
模块 停止 工作 10 s 后 从 DCH 切换 到 FACH 状态 。 然 后 ， 我 们 加 载 一 个 应 用 或 页 面 ， 
周期 性 地 传输 数据 ， 比 如 要 进行 实时 查询 ， 每 10 s 一 次 。 结 果 如 何 呢 ? 设备 可 能 会 
花 几 百 ms 传输 数据 ， 之 后 的 高 功率 状态 完全 浪费 ! 更 糟糕 的 是 ， 由 于 传输 是 间隙 
性 的 ， 设 备 永远 没 机 会 切换 到 低 功 率 状态 ， 从 而 导致 电池 很 快 耗 尽 。 


简 言 之 ， 每 一 次 无 线 电 传输 ， 不 管 数 据 量 有 多 么 少 ， 都 会 切换 到 高 功率 状态 。 传 输 
完成 ， 必 须 等 待 计时 器 超时 才能 切换 回 低 功率 状态 (图 7-9)。 传 输 的 数据 量 大 小 不 
影响 计时 器 的 超时 时 长 。 而 且 ， 设 备 在 切换 到 空 闪 状态 前 ， 可 能 必须 先 经 过 儿 个 中 
间 状 态 。 








cle 





时 间 











7-9: HSPA+ 存在 能 量 尾 ， 因 为 存在 DCH > FACH > IDLE 切换 


计时 器 控制 的 状态 切换 导致 “能 量 尾 ”(energy tail), “能量 尾 ” 导 致 移动 设备 在 网 络 
访问 中 低 效 的 周期 性 传输 。 首 先 ， 状 态 切 换 有 一 个 延迟 时 间 ， 然 后 ， 传 输 开始 ， 最 终 
无 线 电 模块 空间 ， 白 白地 耗 电 ， 直 到 所 有 计时 器 超时 ， 设 备 才 切 换 到 低 功 率 状 态 。 
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46% 的 电量 消耗 仅 传输 0.2% 的 数据 
AT&T Labs Research 发 表 过 一 篇 关于 移动 应 用 资源 占用 的 研究 论文 (“Profiling 
Resource Usage for Mobile Applications”) ， 分 析 了 很 多 流行 移动 应 用 的 网 络 和 电池 
效率 。 其 中 ，Pandora 是 无 线 网 络 中 低 效率 间隙 性 网 络 访问 的 代表 。 


Pandora 用 户 在 播放 歌曲 时 ， 应 用 会 把 整 首 歌 曲 以 流 的 形式 一 次 性 下 载 下 来 。 这 
样 做 是 正确 的 ， 占 有 尽量 多 的 数据 ， 然 后 尽 可 能 早 一 点 关闭 无 线 电 模块 嘛 。 可 是 ， 
在 下 载 歌 曲 之 后 ， 该 应 用 会 启动 一 个 周期 性 的 听众 评测 ， 每 隔 60 秒 就 发 送 一 次 分 
析 数 据 。 最 终结 果 如 何 ? 分 析 信 标 数据 只 占 总 传输 字 节 的 0.2%， 但 消耗 的 电量 却 
占 应 用 耗 电 总 量 的 46% | 


信 标 数据 很 小 ， 但 RRC 状态 切换 导致 的 能 量 尾 让 无 线 电 模块 长 时 间 处 于 高 功率 
状态 ， 从 而 浪费 了 46% 的 电量 。 事 实 上 ， 把 这 些 分 析 数 据 聚 合 为 更 少 的 请 求 ， 或 
者 在 无 线 电 模块 处 于 活动 状态 时 再 发 送 这 些 听 众 数据 ， 可 以 消除 不 必要 的 能 量 尾 ， 
从 而 将 应 用 的 耗 电量 减少 一 半 |1 








7.4” 端 到 端的 运营 商 染 构 
了 解 了 RRC 和 设备 之 后 ， 接 下 来 我 们 把 视角 放 得 更 大 一 些 ， 看 一 看 运营 商 网 络 中 端 
到 端的 架构 。 我 们 的 目标 并 不 是 成 为 这 方面 的 专家 ， 只 是 想 重点 介绍 那些 直接 影响 
运营 商 网 络 中 数据 流 的 因素 ， 以 及 它们 影响 我 们 应 用 性 能 的 原 








对 


运营 商 网 络 中 的 基础 设施 ， 以 及 各 种 逻辑 和 物理 组 件 的 名 字 ， 取 决 于 部 署 的 网 络 属 
于 哪 一 代 和 什么 类 型 : EV-DO 或 HSPA、3GPP 或 3GPP2， 等 等 。 然 而 ， 这 中 间 还 
是 有 很 多 类 似 的 地 方 ， 本 节 就 来 介绍 一 下 LTE 网 络 的 宏观 架构 。 


为 什么 选 LTE 呢 ? 首先 ， 它 是 运营 商 在 部 署 新 网 络 时 最 可 能 考虑 的 。 其 次 ， 可 能 也 
更 重要 的 ， 就 是 LTE 的 特点 之 一 就 是 架构 简洁 : 组 件 更 少 、 依 赖 更 少 ， 都 能 带 来 更 
好 的 性 能 。 


7.4.1 无 线 接 入 网 络 (RAN) 


RAN (Radio Access Network， 无 线 接 入 网 络 ) 在 任何 运营 商 网 络 中 都 是 第 一 重 
要 的 逻辑 组 件 (图 7-10)， 它 的 主要 任务 是 把 请 求 转发 到 分 配 好 的 无 线 信 道 ， 从 
用 户 设 备 接收 或 者 向 用 户 设 备 发 送 数 据 。 事 实 上 ，RAN 是 一 个 由 无 线 资源 控制 器 
(RRC，Radio Resource Controller) 控制 和 管理 的 组 件 。 在 LTE 中 ， 每 个 无 线 基 站 
(eNodeB ) 都 安装 有 RRC， 人 负责 维 护 RRC 状态 机 并 为 小 区 内 每 个 用 户 分 配 资源 。 




















eNodeB 





无 线 接 入 网 络 (RAN) 











7-10: LTE 无 线 接 入 网 络 : 跟踪 小 区 及 eNodeB 


只 要 邻近 小 区 的 信号 更 强 ， 或 者 当前 小 区 超载 ， 用 户 就 会 被 移交 给 邻近 小 区 。 说 起 
来 容易 ， 事 实 上 移交 过 程 正 是 所 有 运营 商 网 络 中 最 复杂 的 环节 。 如 果 每 个 用 户 的 位 
置 固定 ， 而 且 一 个 信号 塔 就 可 以 覆盖 ， 那 么 静态 的 路 由 拓扑 就 够 了 。 可 是 ， 我 们 都 
知道 ， 事 实 并 非 如 此 : 用 户 是 移动 的 ， 因 此 必然 会 在 信号 塔 之 间 转 移 ， 而 且 转 移 期 
间 不 能 影响 语音 和 数据 通信 。 不 用 说 ， 这 个 问题 可 不 容易 解决 。 


如 果 用 户 的 设备 可 以 与 任何 无 线 信号 塔 关 联 ， 那 我 们 怎么 知道 把 接收 到 的 数据 包 转 
发 到 哪里 呢 ? 当然 ， 肯 定 没 有 魔法 ， 答 案 很 简单 : 无线 接 入 网 络 必须 与 核心 网 络 
通信 ， 以 便 随时 知道 每 一 位 用 户 的 行踪 。 更 进一步 ， 为 了 满足 无 干扰 移交 的 需求 ， 
RAN 还 必须 能 动态 更 新 已 有 信道 和 路 由 ， 不 打 断 用 户 发 起 的 既 有 通信 。 


在 LTE 中 ， 信 号 塔 之 间 的 移交 可 以 在 几 百 ms 间 完 成 ， 但 也 会 导致 物理 层 

心 。 数 据 传 输 的 短暂 间断 。 但 无 论 如 何 ， 用 户 对 这 个 过 程 完 全 没有 意识 ， 对 设 
: 备 上 正在 运行 的 应 用 也 没有 影响 。 但 在 早期 网 络 中 ， 同 样 的 过 程 需要 花 几 
秒 钟 时 间 。 

















可 是 ， 还 不 止 如 此 。 由 于 无 线 电 移交 频繁 ， 特 别 是 在 高 密度 的 市 区 和 办 公 环 境 下 ， 
用 户 设 备 必 须 不 断 进 行 小 区 转移 协商 ， 即 使 设备 处 于 空 用 状态 时 也 不 例外 ， 因 此 会 
消耗 很 多 电能 。 事 实 上 ， 这 里 又 加 入 了 一 个 中 间 层 : 一 或 多 个 无 线 信 号 塔 构成 了 
“跟踪 区 ”， 这 是 由 运营 商定 义 的 一 个 逻辑 上 的 信号 塔 群 。 


核心 网 络 必须 知道 用 户 的 位 置 ， 但 更 多 时 候 ， 它 只 知道 跟踪 区 ， 而 不 知道 哪个 信号 
塔 正在 为 用 户 提供 服务 。 稍 后 我 们 会 提 到 ， 这 对 入 站 数据 发 送 的 延迟 有 重大 影响 。 
相应 地 ， 设 备 也 因此 得 以 在 很 低 的 耗 电量 下 在 同一 跟踪 区 内 转移 : 如果 设备 的 RRC 
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状态 为 空间 ， 设 备 或 无 线 网 络 都 不 会 发 送 通知 ， 因 而 节约 了 电能 。 


7.4.2 ”核心 网 络 

核心 网 络 (图 7-11)， 也 称 为 EPC (Evolved Packet Core， 演 进 分 组 核心 网 )，, 在 
LTE 中 负责 数据 路 由 、 账 户 和 策略 管理 。 简 言 之 ， 它 就 是 把 无 线 网 络 和 公共 互联 网 
连接 到 一 起 的 部 分 。 





无 线 接 入 网 络 (RAN) 核心 网 络 (EPC) 








外 部 网 络 





PCRF 


图 7-11: LTE 核心 网 络 (EPC) : PGOW、 PCRF、SGW 和 MME 











首先 ， 就 是 分 组 网 关 (Packet Gateway) PGW， 它 负责 连接 移动 运营 商 与 公共 互联 
网 。PGW 是 所 有 外 部 连接 的 终点 ， 无 论 协 议 是 什么 。 事 实 上 ， 当 移动 设备 连接 到 运 
营 商 网 络 时 ， 正 是 PGW 负责 给 它们 分 配 和 维护 IP 地 址 。 


运营 商 网 络 中 的 每 一 部 设备 都 有 一 个 内 部 标识 码 ， 与 被 分 配 的 IP 地 址 无 关 。 相 应 
地 ， 当 PGW 接收 到 一 个 分 组 ， 它 会 包装 该 分 组 并 通过 EPC 发 送 到 无 线 接 入 网 络 。 
LTE 对 控制 面 流 量 使 用 SCTP (Stream Control Transmission Protocol， 流 控制 传输 协 
议 ) ， 对 其 他 数据 使 用 GTP (GPRS Tunneling Protocol，GPRS 隧道 协议 ) 和 UDP。 








物理 层 连 接 与 应 用 层 连 接 


由 PGW 分 配 和 维护 设备 IP 地 址 有 一 些 重要 的 暗示。 首先 ， 这 意味 着 无 线 设备 很 
容易 与 多 个 人 地址 关联 。 相 反 ， 如 果 IP 地 址 非常 珍贵 ， 那 么 多 个 设备 可 以 共享 
同一 个 IP 地址， 但 分 配 不 同 的 端口 ， 以 便 对 外 收发 数据 。 换 向 话说 ，PGW 在 这 
里 充当 了 NAT 的 角色 | 事实 上 ， 后 一 种 情形 相当 常见 。 同 一 个 运营 商 卫 地址 可 
以 指定 给 网 络 内 的 几 十 甚至 几 百 部 设备 。 











结果 ， 一 部 设备 的 流量 可 能 源 于 多 个 公共 运营 商 IP 地 址 。 一 个 客户 端 向 多 个 IP 
地 址 请 求 资源 没有 什么 值得 大 惊 小 怪 的 ! 到 了 IPv6 时 代 ， 这 种 情况 可 能 会 发 生变 
化 ， 每 部 设备 最 终 可 能 获得 一 个 唯一 的 IP 地址 。 话 虽 这 么 说 ,但 支持 IPV6 的 运 
营 商 还 很 少 ，IPv6 的 推广 和 应 用 进程 还 很 缓慢 。 


除了 卫 地 址 的 分 配 之 外 ， 更 重要 的 可 能 就 是 要 理解 : 正 因 为 终止 外 部 连接 的 是 
PGW， 因 此 设备 无 线 电 模 块 的 状态 (空闲 、 活 动 、 休 眠 )， 不 会 与 任何 外 部 连接 
的 状态 相关 ， 无 论 是 什么 应 用 协议 1 


关闭 无 线 网 络 中 的 无 线 信 号 ， 就 可 以 断 开设 备 与 无 线 信 号 塔 之 间 的 物理 链 路 。 可 
是 ，TCP 和 UDP 等 已 经 建立 的 高 层 连接 仍然 保持 活动 。 在 必须 发 送 数据 的 时 候 ， 
再 重新 建立 物理 连接 ， 除 了 重新 构建 无 线 通信 环境 所 需 的 RRC 延迟 ， 通 信 可 以 在 
没有 任何 副作用 的 情况 下 恢复 。 











PGW 还 负责 执行 所 有 公共 策略 ， 比 如 分 组 过 滤 和 检测 、Qo5S 分 配 、DoS 保护 等 。 
PCRF (Policy and Charging Rules Function， 策 略 和 计 费 规则 功能 ) 组 件 负 责 维 护 和 
评 佑 这些 针对 分 组 网 关 的 规则 。PCRF 是 逻辑 组 件 ， 即 它 可 以 内 置 于 PGW， 也 可 以 
独立 存在 。 


现在 ， 我 们 假设 PGW 从 公共 互联 网 上 接收 到 了 一 个 分 组 ， 需 要 转发 给 其 网 络 中 的 
一 部 移动 设备 ， 那 么 它 怎么 路 由 该 数据 呢 ? PGW 不 知道 用 户 的 实际 位 置 ， 也 不 知 
道 无 线 接 入 网 络 中 不 同 的 跟踪 区 。 下 一 步 就 该 SGW (Serving Gateway， 服 务 网 关 ) 
和 MME (Mobility Management Entity， 移 动 管 理 实体 ) 上 场 了 。 


PGW 把 所 有 分 组 转发 给 SGW， 但 糟糕 的 是 ，SGW 同样 不 知道 用 户 的 确切 位 置 一 一 
这 正 是 MME 的 一 个 核心 任务 。MME ， 即 移动 管理 实体 ， 实 际 上 是 一 个 用 户 数据 库 ， 
管理 着 网 络 上 所 有 用 户 的 全 部 状态 : 他 们 在 网 络 中 的 位 置 、 账 户 类 型 、 账 单 状 态 、 启 
用 的 服务 ， 以 及 所 有 用 户 元 数据 。 只 要 用 户 在 网 络 中 的 位 置 发生 了 变化 ， 位 置 更 新 信 
息 就 会 发 送 到 MME， 当 用 户 打 开 了 自己 的 手机 时 ，MME 也 要 负责 确认 身份 。 


实际 上 ， 当 分 组 到 达 SGW 时 ，SGW 就 会 向 MME 发 送 一 个 查询 ， 查 询 用 户 的 位 置 。 
MME 返回 的 用 户 位 置信 息 包 含 跟踪 区 和 为 目标 设备 提供 服务 的 特定 信号 塔 的 ID， 
SGW 会 利用 该 信息 建立 到 信号 塔 的 连接 ， 然 后 将 用 户 数据 转发 给 无 线 接 入 网 络 。 
简单 来 说 ， 这 些 就 是 全 部 内 容 了。 这 个 宏观 的 架构 对 几 代 移动 数据 网 络 而 言 都 是 相 
同 的 。 其 中 逻辑 组 件 的 名 字 可 能 会 不 一 样 ， 但 所 有 移动 网 络 基本 上 都 遵循 下 面 这 个 
工作 流程 。 

。 数据 到 达 外 部 的 与 互联 网 相连 的 分 组 网 关 。 

。 为 分 组 网 络 应 用 一 套路 由 和 分 组 策略 。 
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。 将 数据 从 公共 网 关 路 由 到 一 或 多 个 服务 网 关 ， 这 些 服务 网 关 是 无 线 网 络 中 设备 的 
移动 销 点 。 

。 通过 用 户 数据 库 对 网 络 中 的 每 个 用 户 进行 身份 验证 、 账 单 结算 、 服 务 提供 及 位 置 
跟踪 。 

。 确定 了 无 线 网 络 中 用 户 的 位 置 后 ， 用 户 数据 就 会 从 服务 网 关 路 由 到 相应 的 无 线 信 
号 塔 。 

。 无 线 信号 塔 进行 必要 的 资源 分 配 并 与 目标 设备 协商 ,然后 通过 无 线 接口 发 送 数据 。 





LTE 核心 网 络 简化 和 统一 的 架构 


LTE 的 一 个 特点 就 是 其 新 的 EPC 网 络 ， 该 网 络 只 基于 IP 在 一 个 统一 的 网 络 中 传 
输 语音 和 数据 。 这 种 设计 可 以 保证 运营 商 的 成 本 效率 ， 同 时 也 对 网 络 的 性 能 提出 
了 更 高 的 要 求 。 语 音 必 须 低 延迟 ， 而 4G 速度 的 吞吐 量 也 要 更 大 ，。 


EPC 怎么 实现 这 些 目标 呢 ? 当然 ,改进 有 很 多 ， 但 无 论 如 何 ， 与 前 几 代 网 络 最 
主要 的 区 别 还 是 LTE 核心 网 络 的 简化 架构 。 特 别 是 ， 为 了 实现 更 好 的 性 能 ， 删 
除了 某 些 组 件 ， 另 一 些 组 件 被 合并 为 更 少 的 还 辑 组 件 ， 很 多 决策 都 被 转移 到 了 网 
络 边缘 。 

比如 ，LTE 中 的 RRC 由 无 线 信号 塔 (eNodeB) 维护 ， 而 在 前 几 代 网 络 中 ，RRC 
都 是 由 网 络 中 的 更 高 层 (服务 网 关 ) 来 管理 ， 这 样 也 就 在 网 络 控制 流量 时 引入 了 
额外 的 延迟 和 性 能 问题 。 











7.4.3 回程 容量 与 延迟 


在 任何 运营 商 网 络 中 ， 逻 辑 与 物理 组 件 之 间 的 连接 性 及 容量 都 是 影响 性 能 的 重要 因 
素 。LTE 无 线 接口 下 的 用 户 与 信号 塔 之 间 可 以 达到 100 Mbit/s 的 速度 。 We 
塔 在 接收 到 信号 后 ， 必 须 有 足够 的 容量 通过 运营 商 网 络 将 所 有 数据 发 送 给 实际 的 目 
标 。 此 外 ， 不 要 忘 了 一 个 信号 塔 应 该 能 够 同时 服务 于 多 个 活动 用 户 ! 


换 名 话说， 真正 的 4G 体验 可 不 是 部 署 一 个 新 无 线 网 络 那么 简单 。 核 心 网 络 也 必须 
升级 ，EPC 和 无 线 网 络 之 间 必 须 存 在 容量 足够 大 的 链 路 ， 而 且 EPC 组 件 相 较 于 前 几 
代 网 络 ， 必 须 能 以 更 低 的 延迟 处 理 更 高 的 数据 传输 速率 。 





5 
实践 中 ， 一 个 无 线 信号 塔 最 多 可 以 服务 3 个 相 邻 小 区 ， 因 此 很 容易 就 能 累 
心 积 到 上 百 个 活动 用 户 。 简 单 做 一 点 数学 计算 ， 就 能 明白 为 了 匹配 4G 无 线 


ol 


“网 络 的 吞吐 量 ， 每 个 信号 塔 都 必须 有 一 条 专用 的 光纤 链 路 ! 









































不 用 说 ， 这 些 条 件 使 得 4G 网 络 对 运营 商 而 言 是 一 个 昂贵 的 方案 : 所 有 无 线 基 站 都 
要 接 入 光纤 、 高 性 能 路 由 器 ， 等 等 。 实 践 中 ， 经 常 能 够 看 到 网 络 整 体 性 能 受 限 于 运 
营 商 网 络 的 回程 容量 (backhaul capacity) ， 而 非 无 线 接口 。 


这 些 性 能 瓶颈 是 我 们 作为 移动 应 用 开发 人 员 无 法 控制 的 ， 但 它们 却 再 一 次 昭示 了 一 
个 重要 的 事实 : 架构 关系 到 端 到 端的 性 能 。 消 除了 第 一 跳 (也 就 是 无 线 接口 ) 的 瓶 
颈 ， 也 就 是 消除 了 网 络 中 第 二 慢 链 路 的 瓶颈 ， 无 论 是 在 运营 商 网 络 中 ， 还 是 在 通 往 
目的 地 的 其 他 路 径 上 。 


事实 上 ， 这 也 不 是 什么 新 鲜 东 西 了 ， 我 们 早 在 1.4 市 “延迟 的 最 后 一 公里 ”中 就 提 
到 过 这 个 问题 。 连 接 到 4G 网 络 ， 并 不 意味 着 你 能 享受 相应 无 线 接口 提供 的 最 大 和 大 
吐 量 。 相 反 ， 我 们 的 应 用 必须 适应 运营 商 网 络 ， 乃 至 互联 网 上 不 断 变化 的 网 络 条 件 。 


7.5 移动 网 络 中 的 分 组 流 

在 开发 移动 应 用 的 过 程 中 ， 人 们 抱怨 最 多 的 就 是 延迟 时 间 捉 摸 不 定 。 现 在 ， 既 然 我 
们 已 经 了 解 了 RRC 和 移动 网 络 的 宏观 架构 ， 接 下 来 就 可 以 把 这 些 知 识 点 联系 起 来 ， 
看 一 看 端 到 端的 分 组 数据 流 ， 从 而 揭示 出 延迟 时 间 变 化 不 定 的 原因 。 实 际 上 ， 通 过 
分 析 我 们 也 会 明白 ， 其 中 很 多 可 变性 其 实 很 大 程度 上 还 是 可 以 预测 的 ! 












































7.5.1 初始 化 请 3 
我 们 假设 用 户 已 经 通过 了 4G 网 络 的 验证 ， 移 动 设备 处 于 空闲 状态 。 现 在 ， 用 户 打 
开 浏 览 器 ， 输 入 URL， 点 击 “ 前 往 ”。 接 下 来 会 发 生 什么 ? 


首先 ， 由 于 手机 处 于 空间 RRC 状态 ， 因 此 无 线 电 模块 必须 与 附近 的 信号 塔 同 步 ， 然 
后 发 送 一 个 请 求 ， 以 便 建立 无 线 通 信 环 境 〈 图 7-12， 第 中 步 )， 此 次 协商 需要 手机 
与 信号 塔 之 间 的 几 次 往返 ， 可 能 需要 花 100 ms。 如 果 是 前 几 代 网 络 ， 那 RRC 由 服 
务 网 关 负 责 管理 ， 这 个 协商 过 程 要 长 得 多 ， 可 达 几 秒 钟 。 


建立 了 无 线 通信 环境 后 ， 设 备 就 会 从 信号 塔 得 到 相应 资源 ， 从 而 能 够 以 特定 的 速度 
和 功率 传输 数据 (第 @ 步 )。 用 户 数据 从 无 线 电 模块 传输 到 信和 号 塔 的 时 间 称 为 用 户 面 
单 向 延迟 ， 在 4G 网 络 中 大 约 要 人 花 5 ms。 实 际 上 ， 由 于 需要 RRC 切换 ， 第 一 个 分 组 
花 的 时 间 比 较 多 ， 但 只 要 无 线 电 模 块 保 持 高 功率 状态 ， 后 续 分 组 的 延迟 时 间 都 是 恒 
定 的 ， 也 就 是 第 一 跳 的 延迟 时 间 。 
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无 线 接 入 网 络 (RAN) : 核心 网 络 (EPC) 


外 部 网 络 











(人 一 控制 面 延迟 RRC 协商 ，< 100 ms) 











3 面 单 向 延迟 (从 设备 到 信号 塔 ，< 5 ms) 








© 
: 


G)— 骨干 及 核心 网 络 延 迟 (延迟 不 定 ) 








(4) 一 > 互联 网 路 由 延迟 (延迟 不 定 ) 





7-12: LTE 请 求 流 的 延迟 时 间 

不 过 ， 还 没有 完 ， 现 在 只 是 把 分 组 从 设备 传输 到 了 无 线 信 号 塔 ! 然后 ， 分 组 还 要 通 
过 核心 网 络 从 SGW 传输 到 PGW (第 @ 步 )， 再 向 外 传 到 公共 互联 网 (第 四 步 )。 遗 
憾 的 是 ， 这 条 路 径 上 的 延迟 时 间 4G 标准 也 无 法 保证 ， 因 运营 商 而 异 。 


二 六 


4 在 很 多 已 部 署 的 4G 网络 中 ， 只 要 设备 处 于 连接 状态 ， 这 种 端 到 端的 延迟 
A 
0%. 








。 一 般 为 30~100 ms。 换 句 话说 ， 不 包含 由 最 初 的 分 组 带 来 的 控制 面 延 迟 。 
心事 实 上 ， 无 线 网 络 第 一 跳 大 约 为 5 ms， 其 余 时 间 (25~95 ms) 就 是 在 运营 
商 核心 网 络 中 路 由 和 传输 的 时 间 。 











下 面 ， 再 假设 浏览 器 已 经 取得 了 请 求 的 页 面 ， 用 户 正在 浏览 内 容 。 无 线 电 模块 已 经 
空间 了 几 十 秒 钟 了 ， 这 意味 着 RRC 很 可 外 ee DRX 状态 ( 见 7.3.2 
节 “LTE RRC 状态 机 ”) ， 从 而 节省 电量 ， 同 时 也 释放 网 络 资源 供 其 他 用 户 使 用 。 此 
时 ， 用 户 又 想 在 浏览 器 中 打开 另 一 个 页 面 ， 也 就 是 触发 了 一 eed 接 下 来 又 会 
发 生 什么 呢 ? 


大 致 的 过 程 与 前 面 所 述 是 一 样 的 ， 只 不 过 因为 设备 处 于 休眠 (DRX) 状态 ， 设 备 与 
无 线 信号 塔 间 的 协商 速度 要 稍微 快 一 些 (图 7-12， 第 @ 步 )， 即 从 休眠 到 连接 不 超 
过 50 ms ( 表 7-9)。 














总 之 ， 用 户 发 出 的 一 次 新 请 求 总 会 导致 一 些 不 同 的 延迟 。 


控制 面 延 迟 

由 RRC 协商 和 状态 切换 导致 的 固定 的 、 一 次 性 的 延迟 时 间 ， 从 空闲 到 活动 少 于 
100 ms， 从 体 眼 到 活动 少 于 50 ms。 

用 户 面 延 迟 

应 用 的 每 个 数据 分 组 从 设备 到 无 线 电 信号 塔 之 间 都 要 花 的 固定 的 时 间 ， 少 于 5 ms。 
核心 网 络 延 迟 

分 组 从 无 线 电 信号 塔 传输 到 分 组 网 关 的 时 间 ， 因 运营 商 而 不 同 ， 一般 为 30~ 
100 ms。 


互联 网 路 由 延迟 
从 运营 商 分 组 网 关 到 公共 互联 网 上 的 目标 地 址 所 花 的 时 间 ， 可 变 。 


前 两 个 延迟 时 间 都 是 4G 标准 规定 的 ， 核 心 网 络 延迟 因 运 营 商 而 异 ， 最 后 一 个 延迟 
可 以 通过 把 服务 器 放 到 离 用 户 较 近 的 地 方 来 缩短 (参见 1.3 市 “光速 与 传播 延迟 ”)。 








移动 网 络 中 的 延迟 与 抖动 
移动 网 络 的 主要 问题 其 分 组 延迟 的 摇摆 不 定 ， 或 者 叫 拌 动 。 没 错 ， 确 实 有 一 些 相 
关 组 件 会 影响 延迟 。 但 是 ， 知 道 了 第 一 个 分 组 触发 RRC 状态 切换 ， 从 而 导致 的 控 
制 面 延迟 之 后 ， 你 会 发 现 性 能 比 想 象 得 要 好 预测 得 多 。 
在 LTE 中 ， 控 制 面 延迟 最 多 100 ms。 而 在 LTE Advanced 中 ， 这 个 时 间 可 以 低 至 
50 ms。 不 过 ， 在 早期 几 代 网 络 中 ， 这 个 延迟 可 能 达到 几 秒 钟 ! 
其 次 是 核心 网 络 延 迟 ， 这 部 分 延迟 在 移动 网 络 中 经 常 占 到 分 组 总 延迟 的 相当 部 分 。 
有 具体 的 延迟 时 间 因 各 代 网 络 而 不 同 ， 运 营 商 的 基础 设施 对 核心 网 络 延迟 也 会 产生 
影响 。 虽 然 很 少 有 运营 商 公开 宣传 自己 的 延迟 时 间 (或 许 是 因为 没有 什么 值得 炒 
作 的 ) ， 但 你 往往 可 以 在 “常见 问题 ”中 找到 答案 。 
比如 美国 最 大 的 移动 运营 商 AT&T， 就 为 不 同 代 网 络 的 核心 网 络 延 迟 给 出 了 如 下 
期 望 值 ， 这 些 值 在 很 大 程度 上 代表 了 行业 水 平 。 
表 7-10: AT&T 部 署 的 2~4G 网 络 的 延迟 时 间 


LTE HSPA+ HSPA EDGE GPRS 
延迟 时 间 | 40~50 ms 100~200 ms 150~400 ms 600~750 ms 600~750 ms 





我 们 知道 ， 地 球 赤 道 周 长 为 40 074 km， 光 绕 地 球 一 周 需 时 133.7 ms。 也 就 是 说 ， 
每 一 次 移动 请 求 平均 至 少 要 花 光 绕 地 球 一 周 的 时 间 1 
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7.5.2 ”入 站 数据 流 

下 面 再 看 一 看 相反 的 过 程 : 用 户 设 备 处 于 空闲 状态 ， 但 有 一 个 数据 分 组 要 从 PGW 路 由 
到 用 户 (图 7-13)。 没 错 ， 所 有 连接 都 终止 于 PGW， 因 而 设备 才 得 以 空 亲 (无 线 电 模 
块 关 闭 ) ， 但 设备 之 前 建立 的 连接 (比如 长 TCP 会 话 ) 可 能 在 PGW 中 仍然 是 活动 的 。 











无 线 接 入 网 络 (RAN) ; 核心 网 络 (EPC) 


外 部 网 络 





(一 互联 网 路 由 延迟 (延迟 不 定 ) 
人)-(G6) 一 > 洒 叶 及 控制 面 延迟 (RRC 协 商 ，< 100 ms) 
(6@) 一 > 骨干 及 核心 网 络 延迟 (延迟 不 定 ) 








7) 一 > 用 户 面 单 向 延迟 (从 设备 到 信号 塔 ，< 5 ms) 











7-13: LTE 入 站 数据 流 延 迟 


如 前 所 述 ，PGW 会 把 入 站 分 组 路 由 到 SGW (第 四 步 )，SGW 进一步 查询 MME。 
然而 ，MME 可 能 不 知道 当前 为 用 户 服务 的 信号 塔 的 确切 位 置 (还 记得 吗 ， 一 堆 信 
号 塔 构成 一 个 “跟踪 区 ”) 。 用 户 只 要 进入 不 同 的 跟踪 区 ， 其 位 置 就 会 在 MME 中 得 
到 更 新 。 但 同一 跟踪 区 内 信号 塔 间 的 转移 ， 不 会 触发 MME 的 更 新 。 


为 此 ， 如 果 设 备 处 于 空 闪 状态 ，MME 会 向 当前 跟踪 区 内 的 所 有 信号 塔 发 送 一 条 寻 
呼 消息 〈 第 思 步 )， 收 到 消息 的 信号 塔 接着 通过 共享 的 无 线 信道 广播 一 条 通知 (第 @ 
步 )， 告 知 设备 应 该 重建 无 线 通信 环境 ， 以 便 接收 数据 。 设 备 周期 性 地 唤醒 以 监听 寻 
呼 消息 ， 如 果 在 寻 呼 列表 中 发 现 了 自己 ， 它 就 会 向 无 线 电 信号 塔 发 送 一 条 协商 请 求 ， 
请 求 重 建 无 线 通信 环境 。 

无 线 通 信 环 境 重 建 之 后 ， 负 责 协商 的 信号 塔 向 MME 回 发 一 条 消息 (第 @ 步 )， 表 示 它 
正在 为 用 户 服务 。 然 后 ，MME 向 服务 网 关 返 回 一 个 应 答 ， 服 务 网 关于 是 就 会 把 数据 路 
由 到 该 信号 塔 〈 第 @ 步 )， 该 信号 塔 再 把 数据 转发 给 目标 设备 (第 〇 9 步 )。( 还 能 咋 样 ? ) 
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设备 一 旦 处 于 连接 状态 ， 无 线 信 号 塔 与 服务 网 关 之 间 就 会 建立 一 条 直 连 信道 ， 从 而 
让 后 续 到 达 的 数据 能 跳 过 第 @ ~ @ 步 〈 不 用 再 经 过 寻 呼 )， 直 接 被 转发 到 信号 塔 。 换 
句 话 说， 仍然 是 第 一 个 分 组 的 延迟 较 长 ! 必须 记 住 。 


增 们 





对 于 IP 及 其 上 面 的 所 有 层 ， 以 及 我 们 的 应 用 而 言 ， 上 述 分 组 数据 流 是 完 

人 Q 4 ， 透 明 的 。PGW、SGW 和 eNodeB 会 在 每 一 步 负 责 缓冲 分 组 ， 确 保 可 以 把 

全 ”它们 送 达 设 备 。 实 践 中 ， 可 以 观察 到 分 组 到 达 时 间 中 的 延迟 拉动 ， 负 责 控 
制 面 协商 的 第 一 个 分 组 导致 的 延迟 最 高 。 


7.6” 异 质 网 络 (HetNet) 


现 有 4G 无 线 及 调制 技术 已 经 接近 无 线 信道 的 理论 极限 。 事 实 上 ， 下 一 个 改进 无 线 
性 能 的 研究 方向 不 在 无 线 接口 ， 而 在 智能 无 线 网 络 拓扑 。 有 具体 来 说 ， 通 过 广泛 部 署 
多 层 异 质 网 络 (heterogeneous networks，HetNets) ， 可 以 促进 小 区 内 协调 、 转 移 和 
干扰 管理 等 多 方面 的 改进 。 


HetNet 背后 的 核心 思想 非常 简单 : 覆盖 较 大 地 理 区 域 的 无 线 网 络 容 易 导 致 用 户 竞 
和 争 ， 因 此 不 如 用 更 小 的 小 区 来 覆盖 这 些 区 域 (图 7-14) ， 实 现 每 个 小 区 的 路 径 损失 
最 小 、 传 输 功 率 最 低 ， 从 而 让 所 有 用 户 享受 到 更 高 的 性 能 。 
































毫 微小 区 

















图 7-14: 异 质 网 络 信息 图 (爱立信 ) 


在 低 密 度 无 线 环 境 下 ， 一 个 大 小 区 可 以 覆盖 几 十 公里 ， 但 在 实践 中 ， 高 密度 的 城市 
中 心 区 和 办 公 区 ， 和 覆盖 范围 只 能 达到 50~300 m ! 换 名 话说， 只 能 覆盖 一 个 街区 或 
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几 栋 楼 。 相 对 而 言 ， 小 小 区 只 覆盖 某 一 栋 楼 ， 微 小 区 则 服务 于 几 层 楼 ， 而 毫 微小 区 
则 覆盖 一 个 小 房间 并 利用 现 有 频 宽 服务 作为 无 线 回 程 。 


不 过 ，HetNet 并 不 是 简单 地 用 大 量 小 型 小 区 替代 大 型 小 区 ， 而 是 实现 了 小 区 的 分 
层 ! 通过 部 署 层 倒 式 无 线 网 络 ，HetNet 能 够 提供 更 高 的 网 络 容 量 ， 和 覆盖 更 广泛 的 地 
理 区 域 。HetNet 面临 的 挑战 是 如 何 降低 和 干扰， 提供 足够 的 上 行 容 量 ， 以 及 制定 和 改 
进 在 不 同 网 络 层 之 间 无 颖 迁移 的 协议 。 


这 些 对 于 我 们 开发 移动 应 用 的 人 来 说 意味 着 什么 呢 ? 意味 着 我 们 应 该 预见 到 不 同 小 
区 之 间 的 迁移 次 数 会 明显 增多 ， 因 此 要 想 办 法 适应 。 而 且 ， 由 此 带 来 的 延迟 及 吞吐 
量 性 能 变动 也 会 非常 明显 。 





建 模 和 管理 无 线 网 络 容量 


移动 运营 商 通 常 使 用 微小 区 把 信号 覆盖 范围 从 室内 扩展 到 信号 质量 较 差 的 室外 ， 
或 者 在 手机 密集 区 (比如 大 型 公共 场所 、 会 议 厅 、 体 育 场 、 火 车 站 ， 等 等 ) 用 于 
扩充 网 络 容 量 。 有 的 微小 区 是 永久 部 署 的 ， 而 另 一 些 可 能 只 为 特定 场合 部 署 一 一 
无 线 容量 的 规划 与 建 模 (图 7-15) 既是 艺术 也 是 科学 1 
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7-15; 使 用 TamoGraph 进行 无 线 容量 规划 


图 7-15 中 的 TamoGraph Site Survey 是 专门 用 于 建 模 的 软件 ， 通 常用 于 对 物理 环 
境 、 活 路 用 户 数 量 ， 以 及 可 用 的 无 线 技术 (图 中 的 Wi-Fi) 建 模 ， 以 辅助 确定 网 络 
热点 的 必要 数量 、 位 置 和 配置 。 











7.7 ”真实 的 3G、4G 和 Wi-Fi 性 能 


此 时 此 刻 ， 有 读者 可 能 禁不住 想 问 : 3G 或 4G 网 络 中 的 这 些 协议 、 网 关 和 协商 机 制 
如 此 复杂 真 的 有 必要 吗 ? 你 看 Wi-Fi， 不 是 要 简单 得 多 吗 ， 而 且 实 践 中 似乎 也 用 得 
很 好 啊 ! 


这 个 问题 可 不 好 回答 ， 正 如 我 们 前 面 介 绍 的 ， 度 量 无 线 网 络 的 性 能 离 不 开 各 种 环境 
和 技术 性 因素 。 更 进一步 ， 这 个 问题 的 答案 还 取决 于 选择 什么 样 的 评估 标准 : 


。 电池 性 能 重要 ， 还 是 网 络 性 能 重要 ， 

。 单 用 户 性 能 ， 还 是 全 网 吞吐 量 性 能 ， 

。 延迟 性 能 ， 还 是 分 组 抖动 性 能 ， 

。 成 本 ， 还 是 部 署 的 可 行 性 ; 

。 满足 政府 及 政策 管制 要 求 的 能 

。 其 他 很 多 标准 。 

不 过 ， 尽 管 干系 方 众多 (用 户 、 运 营 商 、 移 动 设备 制造 商 ， 等 等 )， 而 且 各 方 都 有 自 
己 的 优先 标准 ， 最 新 4G 网 络 的 测试 结果 表明 它 仍然 是 非常 有 前 景 的 。 事实 上 ，4G 
在 网 络 延迟 、 吞 吐 量 和 容量 等 这 些 关键 指标 上 都 胜 过 Wi-Fi ! 








举 一 个 具体 的 例子 吧 ， 美 国 密歇根 大 学 和 AT&T 实验 室 的 一 个 联合 研究 项 目 曾 在 美国 
并 内 做 过 测试 ， 比 较 了 4G、3G 和 Wi-Fi (802.11g，2.4 GHz) 的 性 能 (图 7-16)。 





。 通过 46 个 独立 的 测量 实验 室 节 点 测量 性 能 ， 这 些 节点 都 是 用 于 互联 网 测量 的 开 
放 性 平台 ,测量 使 用 的 是 开源 测量 客户 端 MobiPerf。 
。 2011 年 底 ， 在 两 个 月 时 间 内 ， 定 期 对 3300 名 用 户 进行 了 测量 。 
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图 7-16: 对 Wi-Fi、LTE 和 3G 性 能 的 测量 结果 分 析 
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Ed 人 
的 每 种 连接 类 型 的 箱 线 图 浓缩 了 很 多 有 用 的 信息 : 线 表示 整体 分 布 的 范围 ， 
we 。 箱 表示 分 布 的 下 四 分 位 和 上 四 分 位 ， 箱 中 的 黑色 水 平 线 是 中 位 值 。 

人 

















当然 ， 一 次 测试 并 不 能 找 出 普遍 规律 ， 特 别 是 在 关系 到 性 能 的 情况 下 。 但 这 个 测试 
结果 无 论 如 何 都 很 值得 期 待 : 早期 的 LTE 网 络 展示 出 了 巨大 的 吞吐 量 ， 而 更 让 人 兴 
奋 的 则 是 往返 时 间 (RTT) 和 分 组 抖动 时 间 相 对 于 其 他 无 线 标准 ， 明 显 更 加 稳定 。 
换 句 话说 ， 这 次 测试 至 少 表明 ，LTE 的 性 能 好 过 Wi-Fi， 同 时 也 表明 性 能 提升 是 可 
能 的 ， 因 此 所 有 复杂 性 也 就 值得 了 ! 移动 网 络 不 一 定 慢 。 事 实 上 ， 我 们 有 理由 相信 ， 
移动 网 络 的 速度 还 会 更 快 。 








5 
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要 了 解 关于 4G 网 络 性 能 研究 、 分 析 和 结论 的 更 多 信息 ， 请 参考 在 移 
， 动 系统 、 应 用 及 服务 国际 大 会 MobiSys 2012 上 发 表 的 文章 “A Close 
~ Examination of Performance and Power Characteristics of 4G LTE Networks” 


(关于 4G LTE 网 络 性 能 及 功率 特点 的 仔细 研究 )。 

















第 8 和 章 


移动 网 络 的 优化 建议 





首先 ， 通 过 持久 连接 、 将 服务 器 和 数据 部 团 到 接近 用 户 的 地 方 、 优 化 TLS 部 署 ， 以 
及 我 们 介绍 的 其 他 协议 优化 策略 来 降低 延迟 时 间 只 会 对 移动 应 用 更 重要 。 当 然 ， 对 
移动 应 用 而 言 ， 延 迟 时 间 和 吞吐 量 都 至 关 重要 。 类 似 地 ， 所 有 Web 性 能 最 佳 实践 也 
同样 适用 ， 你 现在 就 可 以 翻 到 第 10 章 。 


不 过 ， 移 动 网 络 也 对 我 们 的 性 能 策略 提出 了 新 的 、 独 特 的 要 求 。 设 计 移动 互联 网 应 
用 ， 必 须 认真 规划 和 考量 设备 的 形态 限制 以 展示 内 容 ， 考 虑 无 线 接口 的 性 能 特性 ， 
以 及 电池 使 用 时 间 。 上 述 三 个 方面 密 不 可 分 。 


或 许 是 因为 表现 层 最 容易 控制 ， 再 加 上 响应 式 设计 之 类 的 概念 ， 使 得 它 抓 足 了 人 们 
的 眼球 。 然 而 ， 大 多 数 应 用 还 是 不 尽 人 意 ， 究 其 原因 就 是 对 网 络 性 能 的 错误 评 佑 : 
应 用 的 协议 相同 ， 但 物理 传输 层 的 差别 却 有 很 多 限制 ， 如 果 对 这 些 限 制 估计 不 足 ， 
就 会 导致 响应 速度 慢 、 延 迟 时 间 摇 摆 不 定 ， 最 终 导 致 用 户 体验 大 打折 扣 。 此 外 ， 非 
理性 的 联网 操作 也 会 对 设备 电池 的 使 用 时 间 造 成 极 大 的 负面 影响 。 


对 于 这 三 方面 的 限制 ， 没 有 普 适 的 解决 方案 。 针 对 表现 层 、 联 网 和 电池 使 用 时 间 ， 
都 有 一 些 最 佳 实践 ， 但 这 些 做 法 经 常 相互 冲突 。 最 终 ， 还 是 要 靠 你 和 应 用 在 需求 中 
取得 平衡 。 但 有 一 件 事 是 肯定 的 : 忽视 其 中 任何 一 个 限制 都 将 对 你 不 利 。 


我 们 不 会 详细 讨论 表现 层 ， 因 为 平台 和 应 用 类 型 对 表现 层 的 影响 很 大 ， 而 且 讨 论 这 
方面 的 图 书 也 已 经 有 很 多 了 。 可 是 ， 无 论 制造 商 是 谁 ， 无 论 什 么 操作 系统 ， 移 动 网 
络 的 无 线 及 电池 限制 都 是 普 适 的 ， 因 此 这 两 方面 将 是 本 章 讨论 的 重点 。 
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本 章 ， 特 别 是 接 下 来 儿 页 中 , “移动 应 用 ”这 个 词 将 包含 广泛 的 意义 。 我 们 
AS 4 ， 所 有 关于 移动 网 络 性 能 的 讨论 ， 同 样 也 适用 于 本 机 应 用 和 浏览 器 应 用 ， 而 
证 与 平台 及 浏览 器 制造 商 无 关 。 





























8.1 节约 用 电 


说 到 移动 设备 ， 市 约 用 电 是 设备 制造 商 、 运 营 商 、 应 用 开发 者 ， 以 及 应 用 的 用 户 都 
会 关心 的 话题 。 在 拿 不 准 或 不 知道 某 个 功能 为 什么 存在 或 怎么 实现 时 ， 不 妨 问 自己 
一 个 简单 的 问题 : 这 个 功能 对 电量 有 什么 影响 ， 或 者 它 怎么 做 到 省 电 ? 事实 上 ， 这 
是 一 个 对 应 用 的 所 有 功能 都 适用 的 问题 。 


移动 网 络 的 性 能 与 电池 使 用 时 间 天 生 联 系 在 一 起 。 而 且 ， 为 了 市 约 用 电 ， 无 线 接口 
的 物理 层 还 专门 针对 如 下 限制 (或 事实 ) 做 出 了 优化 : 


。 全 功率 打开 无 线 电 模块 只 消 儿 小 时 就 可 耗 尽 电量 ， 
。 对 无 线 电 功率 的 需求 随 着 无 线 标准 演进 与 代 俱 增 ， 
。 无 线 电 模块 的 耗 电量 仅 次 于 设备 的 屏幕， 

。 数据 传输 时 无 线 电 通信 的 耗 电 过 程 是 非 线 性 的 。 


知道 了 这 些 之 后 ， 在 开发 移动 应 用 时 ， 就 该 尽量 少 用 无 线 电 接口 。 当 然 ， 并 不 是 说 
完全 不 能 使 用 无 线 电 模块， 毕竟 移动 联网 应 用 肯定 还 是 要 上 网 的 ! 只 是 考虑 到 无 线 
电 通信 直接 关系 到 电 凶 使 用 时 间 ， 我 们 应 该 尽 最 大 可 能 在 无 线 电 开 局 时 传输 数据 ， 
而 尽量 把 唤醒 无 线 电 以 传输 数据 的 次 数 减 到 最 少 。 




















二 六 


ogg 虽然 Wi-Fi 也 使 用 无 线 接口 传输 数据 ， 但 重要 的 是 必须 知道 Wi-Fi 的 底层 
全 | 和， 8 站， 和 时 和 特点。 过 和 与 26、36 和 4 

42， 络 相 比 ， 都 有 根本 不 同 (参见 7.3.1 节 )。 因 此 ， 应 用 联网 时 的 行为 自然 
会 因 使 用 Wi-Fi 或 移动 网 络 而 有 所 不 同 。 
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使 用 AT&T 应 用 资源 优化 器 测量 能 源 消耗 
谁 都 知道 应 该 节约 使 用 电池 ,但 当前 大 多 数 平台 部 没有 给 开发 人 员 配 备 必需 的 工 
具 ， 以 测量 和 优化 应 用 。 可 喜 的 是 ， 我们 还 可 以 找到 第 三 方 工具 ， 比 如 AT&T 免 
费 的 Application Resource Optimizer (ARO， 应 用 资源 优化 器 ) 工具 包 (图 8-1)。 
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图 8-1: AT&T 应 用 资源 优化 器 


ARO 包含 两 个 组 件 : 收集 器 和 分 析 器 。 其 中 ， 收 集 器 是 一 个 后 台 Android 应 用 
(可 以 在 手机 或 模拟 器 中 运行 )， 用 于 捕获 传输 的 数据 分 组 、 无 线 模块 活动 信息 及 
其 他 与 手机 的 交互 行为 。 要 想 记 录用 电 情 况 ， 可 以 打开 收集 器 ， 点 击 记 录 ， 使 用 
应 用 ， 然 后 将 记录 结果 复制 到 系统 中 。 


得 到 记录 结果 后 ， 可 以 通过 分 析 器 打开 它 ， 从 而 得 知 无 线 电 状态 、 电 量 消耗 、 应 
用 的 通信 模式 等 信息 。 另 外 ， 分 析 器 有 一 个 很 不 错 的 功能 ， 即 针对 常见 的 性 能 陷 
阱 提供 建议 ， 比 如 没有 压缩 、 重 复 传输 数据 ， 等 等 。 


有 两 点 需要 注意 : 电量 消耗 和 无 线 电 状态 是 通过 设备 及 无 线 网 络 类 型 的 特殊 模型 
生成 的 。 换 向 话说 ， 生 成 的 数值 并 不 是 设备 在 使 用 时 的 真实 值 ， 而 是 根据 特定 模 
型 参数 得 到 的 估计 值 。 从 好 的 一 面 看 ， 你 可 以 利用 它 导 入 不 同 的 设备 和 网 络 模型 ， 
比较 不 同 模型 (比如 3G、4G) 下 的 电量 消耗 。 


第 二 点 ， 收 集 器 只 能 在 Android 平台 运行 ， 而 ARO 分 析 器 则 可 以 接收 任何 常规 的 
分 组 跟踪 记录 (pcap) 文件 ， 可 以 使 用 tcpdump 或 其 他 兼容 工具 生成 ; iOS 用 户 可 
以 使 用 tcpdump。 


要 了 解 ARO 工具 包 ， 可 以 访问 developer.att.com/ARO/OreillyHPBN。 
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8.2 ”消除 周期 性 及 无 效 的 数据 传输 


我 们 知道 ， 无 论 传输 多 少数 据 ， 移 动 无 线 通信 和 总 会 消耗 恒定 电量 ， 从 而 导致 无 线 模 
块 进入 高 功率 状态 。 因 此 ， 对 于 耗 电 而 言 ， 根 本 不 存在 什么 “ 耗 电 少 的 请 求 ”( 参 见 
7.3.5 市 “ 低 效率 的 周期 性 传输 ”)。 那 么 ， 进 一 步 归 纳 就 可 以 得 到 如 下 规则 : 


。 轮 询 在 移动 网 络 中 代价 极 高 ， 少 用 ， 

。 尽 可 能 使 用 推送 和 通知 ， 

。 出 站 和 入 站 请 求 应 该 合并 和 汇总 ; 

。 非 关键 性 请 求 应 该 推迟 到 无 线 模块 活动 时 进行 。 


一 般 来 说 ， 推 送 比 轮 询 效果 更 好 。 但 频率 过 高 的 推送 与 轮 询 也 不 相 上 下 。 如 果 磁 到 
实时 更 新 的 需求 ， 应 该 考虑 下 列 问题 。 


。 最 佳 更 新 间隔 多 长 ， 是 否 符合 用 户 预 期 ? 

。 除了 固定 的 更 新 间隔 ， 能 否 因 地 因 时 制 宜 ? 
。 入 站 或 出 站 请 求 能 否 集合 为 更 少 的 网 络 调用 ? 
。 入 站 或 出 站 请 求 能 否 推迟 到 以 后 发 送 ? 

















3 





、 对 推送 而 言 ， 原 生 应 用 可 以 访问 平台 专 有 的 推送 服务 ， 因 此 应 该 尽 可 能 使 

心 。 用 。 对 Web 应 用 来 说 ， 可 以 使 用 SSE (Server Sent Events， 服 务 器 发 送 事 

起， 件 ) 和 WebSocket 以 降低 延迟 时 间 和 协议 消耗 ， 尽 可 能 不 使 用 轮 询 和 更 耗 
资源 的 XHR 技术 。 














基于 时 间 间 隔 、 环 境 、 用 户 偏好 ， 黄 至 电池 电量 ， 简 单 地 把 多 个 通知 集合 到 一 个 推 
送 事 件 中 ， 可 以 显著 提升 任何 应 用 的 电池 效率 。 后 台 应 用 尤其 适合 这 一 策略 ， 因 为 
它们 经 常 要 以 这 种 方式 访问 网 络 。 





内 格 尔 及 有 效 的 服务 器 推送 
因为 有 内 格 尔 (Nagle) 算法 ，TCP 的 拥 原 一定 会 认可 请 求 聚 合 和 绑 定 的 建议 ， 当 
然 不 是 在 应 用 层 ! 内 格 尔 算法 尝试 将 多 个 TCP 消息 组 合 为 一 个 分 组 ， 以 期 减少 协 
议 消耗 和 需要 传输 的 分 组 数量 。 不 用 说 ， 移 动 应 用 同样 是 这 一 技术 的 用 武之 地 。 


简单 的 策略 是 ， 可 以 在 服务 器 上 根据 时 间 、 数 量 或 大 小 来 聚合 消息 ， 而 不 是 每 个 
消息 都 单独 推送 一 次 。 但 更 深入 也 更 有 效 的 做 法 ， 则 是 只 在 客户 端的 无 线 模块 活 
动 期 间 推 送 更 新 。 比 如 ， 把 消息 推迟 到 客户 端 发 送 请 求 之 后 再 发 送 ， 可 以 利用 那 
些 能 够 监控 客户 端 无 线 状 态 的 服务 。 














举 个 例子 ，GCM (Google Cloud Messaging， 谷 歌 云 消 息 ) 就 是 一 个 可 以 在 Android 
和 Chrome 平台 中 使 用 的 消息 发 送 API， 它 能 聚合 消息 ， 并 只 在 设备 活动 时 发 送 更 
新 。 只 要 把 消息 发 送 给 GCM， 然 后 GCM 就 能 作出 最 优 的 推送 时 间 安 排 。 

遗憾 的 是 ， 目 前 还 没有 功能 类 似 GCM 的 跨 浏 览 器 API， 因 此 不 能 统一 为 所 有 客户 
问 提 供 服 务 。 不 过 ，W3C Push API (参见 www.w3.orge/TR/push-api/) 将 来 有 可 能 
解决 这 个 问题 。 








间 鞭 的 信 标 (beacon) 请 求 〈 比 如 周期 性 的 听众 评测 和 实时 分 析 请 求 ) 很 容易 破坏 
电池 电量 优化 策略 。 这 些 周期 性 的 请 求 对 于 有 线 甚至 Wi-Fi 网 络 没 有 什么 负面 影响 ， 
但 对 无 线 网 络 影响 巨大 。 这 些 信 标 请 求 有 必要 实时 发 送 吗 ? 蕊 怕 借助 日 志 将 请 求 推 
迟到 无 线 模 块 下 一 次 活动 时 发 送 才 是 明智 的 。 总 之 ， 需 要 认真 对 待 后 台 的 这 些 周期 
性 操作 ， 同 时 还 要 密切 关注 第 三 方 库 和 代码 片段 访问 网 络 的 模式 。 


最 后 一 点 ， 虽 然 我 们 一 直 在 说 电池 ， 但 也 不 要 忘 了 渐进 增强 和 增 量 加 载 等 技术 依赖 
的 间歇 性 网 络 访问 ， 会 带 来 较 长 的 延迟 ， 因 为 RRC 状态 需要 切换 ! 还 记得 每 次 状态 
切换 都 会 导致 移动 网 络 控制 面 的 较 大 延迟 吧 ， 每 次 切换 都 可 能 增加 几 百 甚至 几 千 ms 
的 延迟 时 间 。 对 于 用 户 发 起 或 交互 性 的 流量 ， 这 方面 的 代价 非常 之 大 。 











计算 后 台 更 新 的 电量 消耗 
为 说 明 周期 性 轮 询 对 电池 使 用 时 间 的 影响 ， 我 们 可 以 做 一 道 简单 的 数学 题 。 数 值 
虽然 不 一 定 准确 ， 但 也 不 会 跑 出 3G/4G 移动 设备 的 范围 之 外 : 
。 5 Wh 或 18000J 的 电池 容量 (5 Wh x 3600J/Wh); 
。 无 线 电 模块 从 空闲 状态 切换 到 连接 状态 需要 10 Ji 
。 1 分钟 一 次 的 轮 询 ，1 小 时 耗 能 600J (60 x 10J) ; 
。 600 丁 相当 于 电池 容量 的 大 约 3% (600J/18000 了 J) 。 


一 个 应 用 每 小 时 就 要 消耗 3% 的 电量 | 那么 两 个 应 用 不 重合 的 轮 询 ， 要 耗 尽 电 池 ， 
只 需 半 天 时 间 。 当 然 ， 如 果 应 用 频繁 使 用 不 缓冲 的 推送 (比如 ， 每 两 秒 就 推送 一 
次 ) ， 那 么 其 耗 电量 还 会 更 高 ! 

电池 使 用 时 间 优 化 和 更 新 频率 天 生 是 一 对 矛盾 。 实 践 中 ， 要 根据 自己 应 用 的 特定 
需求 来 确定 优化 策略 : 更 新 打包 、 舌 应 性 的 更 新 间隔 、 拉 与 推 结 合 ， 等 等 。 当 然 ， 
还 要 使 用 ARO 或 类 似 的 工具 测量 策略 效果 ， 适 时 调整 。 











消除 不 必要 的 长 连接 
TCP 或 UDP 连接 的 连接 状态 及 生命 期 与 设备 的 无 线 状态 是 相互 独立 的 。 换 句 话说 ， 
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即便 与 运营 商 网 络 仍 维持 着 (两 端 间 ) 连接 不 中 断 ， 无 线 模块 也 可 以 处 于 低 耗 电 状 
态 。 外 部 网 络 的 分 组 到 来 时 ， 运 营 商 无 线 网 络 会 通知 设备 ， 使 其 无 线 模块 切换 到 连 
接 状态 ， 从 而 恢复 数据 传输 。 


明白 了 吗 ， 应 用 不 必 让 无 线 模块 “活动 ”也 可 以 保持 连接 不 被 断 开 。 但 不 必要 的 长 
连接 也 有 可 能 极 大 地 消耗 电量 ， 而 且 由 于 人 们 对 移动 网 络 无 线 通信 的 误解 ， 这 种 情 
况 经 常 发 生 。 这 里 可 以 参考 7.4.2 市 中 的 “物理 层 连 接 与 应 用 层 连 接 ” 和 7.5 市 “ 移 
动 网 络 中 的 分 组 流 ”。 



























































、 状 态 下 保持 连接 ， 可 能 需要 周期 性 (每 5 分 钟 ) 发 送 一 次 Keep-Alive。 如 
> 果 你 觉得 自己 的 Keep-Alive 发 送 太 过 频繁 ， 需 要 先 检查 自己 的 服务 器 、 代 
理 和 负载 均衡 器 配置 ! 


5 
4 大 多 数 移动 运营 商 的 NAT 连接 超时 时 间 为 5~30 分 钟 。 因 此 ， 为 了 在 空闲 
A 
MY 
4 








8.3 预测 网 络 延迟 上 限 

在 移动 网 络 中 ， 一 个 HTTP 请 求 很 可 能 会 导致 一 连 串 长 达 几 百 甚 至 上 几 千 ms 的 网 
络 延迟 。 这 一 方面 是 因为 有 往返 延迟 ， 另 一 方面 也 不 能 忘记 DNS、TCP、TLS 及 控 
制 面 的 延迟 (图 8-2 ) 。 











HTTP 请 求 
1~n 次 往返 














图 8-2: 一 个 “简单 的 ”HTTP 请 求 的 构成 

最 好 的 情况 ， 就 是 无 线 模块 处 于 最 高 功率 状态 、DNS 已 经 提前 解析 完成 ， 而 且 TCP 
连接 是 现成 的 (客户 端 可 以 重用 已 有 的 连接 ， 不 用 再 花 时 间 去 建立 新 连接 )。 可 是 ， 
如 果 连 接 繁 忙 ， 或 不 存在 ， 那 就 必须 在 发 送 数 据 前 经 历 额外 的 往返 。 

为 说 明 额 外 的 网 络 往返 有 多 大 影响 ， 我 们 假设 理想 情况 下 4G 网 络 的 往返 时 间 为 100 ms， 
3.5G+ 网 络 的 往返 时 间 为 200 ms。 





在 3G 网 络 中 ， 仅 RRC 控制 面 延迟 一 项 就 可 以 给 重建 无 线 通 信 环 境 增加 几 百 到 几 
千 ms 的 延迟 ! 无 线 模 块 活动 后 ， 可 能 还 需要 解析 主机 名 和 IP 地 址 ， 然 后 进行 TCP 
握手 ， 这 又 是 两 次 往返 。 然 后 ， 如 果 需 要 安全 信道 ， 可 能 还 需要 额外 两 次 网 络 往返 
(参见 4.3 节 )。 最 后 ， 才 能 发 送 HTTP 请 求 ， 这 最 少 又 是 一 次 往返 ( 表 8-1)。 











表 8-1: 一 个 HTTP 请 求 的 延迟 时 间 








3G 4G 
控制 面 200~2500 ms 50~100 ms 
DNS 查询 200 ms 100 ms 
TCP 握手 200 ms 100 ms 
TLS 握手 200~400 ms 100~200 ms 
HTTP 请 求 200 ms 100 ms 
总 延迟 200~3500 ms 100~600 ms 


就 这 还 没有 考虑 服务 器 响应 时 间 、 响 应 大 小 呢 ， 这 些 也 需要 儿 次 往返 ， 最 多 可 能 达 
到 6 次 。 再 乘 以 往返 时 间 ， 那 么 3G 网 络 的 延迟 可 能 长 达 数 秒 ，4G 网 络 大 约 也 要 
半 秒 | 


8.3.1 考虑 RRC 状 态 切换 

如 果 移 动 设备 已 经 空间 了 几 秒 钟 ， 那 应 该 假设 并 预想 第 一 个 分 组 将 会 导致 几 百 甚至 
几 千 ms 的 额外 RRC 延迟 。 经 验 表 明 ，4G 网 络 会 增加 100 ms，3.5G+ 网 络 会 增加 
150~500 ms， 而 3G 网 络 会 增加 500~2500 ms 一 次 性 的 控制 面 的 延迟 。 


7.3 节 介 绍 的 无 线 电 资源 控制 器 (RRC) 是 专门 设计 用 来 解决 高 耗 电 问题 的 。 但 在 
保证 电池 使 用 时 间 的 同时 ， 各 种 计时 器 、 计 数 器 的 存在 ， 以 及 不 同 无 线 状态 切换 所 
需 的 网 络 协商 ， 也 带 来 了 额外 的 延迟 和 较 低 的 吞吐 量 。 然 而 ，RRC 在 移动 网 络 中 是 
事实 存在 的 ， 无 法 回避 的 。 如 果 你 想 针对 移动 网 络 优化 自己 的 应 用 ， 必 须 在 设计 时 
就 考虑 到 RRC。 


关于 RRC， 以 下 是 我 们 已 经 了 解 的 一 些 常 识 : 


。 RRC 状态 机 因 无 线 标准 不 同 而 不 同 ; 

。 RRC 状态 机 由 无 线 网 络 为 每 部 设备 分 别管 理 ， 

。 RRC 在 必须 传输 数据 时 会 切换 到 高 功率 状态 ; 

。 RRC 在 网 络 配置 的 时 间 超 出 后 会 切换 到 低 功率 状态 ; 

。 (4G) LTE 状态 切换 可 能 花 10~100 ms; 

。 (4G) HSPA+ 状态 切换 与 LTE 相差 无 几 ; 

。 (3G) HSPA 和 CDMA 状态 切换 可 能 花 几 秒 钟 ; 

。 每 次 网 络 传输 ， 无 论 数据 多 少 ， 都 会 导致 能 量 尾 。 

我 们 已 经 讨论 了 为 什么 对 移动 应 用 而 言 ， 节 约 用 电 是 一 个 非常 重要 的 目标 。 而 且 ， 
我 们 也 重点 介绍 了 间隙 传输 的 低 效 率 ， 它 又 是 因 RRC 状态 切换 而 超时 直接 导致 的 
结果 。 不 过 ， 还 有 一 点 需要 注意 : 如 果 设 备 的 无 线 模块 已 经 空间 ， 那 么 在 移动 网 络 
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上 再 次 传输 数据 将 导致 额外 的 延迟 ， 这 个 延迟 在 最 新 的 网 络 上 可 能 有 几 百 ms， 而 在 
3G 或 2G 网 络 上 最 多 则 可 能 达到 几 秒 。 


换 句 话说 ， 尽 管 网 络 会 给 人 一 种 我 们 的 应 用 永远 在 线 的 错觉 但 由 RRC 控制 的 物 
理 层 (也 就 是 无 线 模块 ) 会 不 断 连 接 和 断 开 。 表 面 上 看 这 不 是 什么 问题 ， 但 这 种 由 
RRC 交互 导致 的 延迟 ， 如 果 不 加 重视 的 话 ， 很 可 能 会 打 断 用 户 体验 。 





8.3.2 ” 解 耦 用 户 交 互 与 网 络 通信 

设计 得 好 的 应 用 ， 即 便 底 层 连接 慢 或 者 请 求 时 间 长 ， 通 过 在 UI 中 提供 即时 反馈 也 能 
让 人 觉得 速度 快 。 不 要 把 用 户 交 互 与 网 络 通信 联系 得 太 过 紧密 。 为 给 用 户 最 佳 体验 ， 
应 用 必须 在 几 百 ms 内 响应 输入 ， 有 具体 参见 10.2.1 节 “ 速 度 、 性 能 与 用 户 预 期 ”。 


如 果 必 须发 送 网 络 请 求 ， 那 么 在 后 台 发 ， 但 要 对 用 户 输入 立即 给 出 反馈 。 单 单 控制 
面 延迟 一 项 ， 经 常 就 可 以 让 你 提供 实时 反馈 的 计划 超出 预算 。 因 此 要 针对 高 延迟 做 
足 准 备 ， 虽 然 不 能 “解决 ”核心 网 络 和 了 RRC 带 来 的 延迟 ， 但 你 可 以 与 设计 团队 合 
作 ， 确 保 他 们 在 设计 应 用 时 了 解 这 些 限 制 。 


8.4 面 对 多 网 络 接口 并 存 的 现实 


用 户 不 喜欢 速度 慢 的 应 用 ， 但 由 于 短暂 网 络 错误 导致 的 应 用 崩溃 才 是 体验 最 差 的 。 
我 们 的 移动 应 用 必须 足以 应 对 各 种 常见 的 网 络 错误 : 无 法 访问 的 主机 、 否 吐 量 突然 
下 降 或 延迟 突然 上 升 ， 甚 至 连接 彻底 断 开 。 与 有 线 网 络 不 同 ， 你 不 能 假定 一 次 连接 
成 功 就 能 持续 保持 连接 状态 。 用 户 可 能 正在 移动 ， 可 能 进入 了 高 冲突 、 用 户 多 , 或 
者 信号 差 的 区 域 。 


另外 ， 就 像 设计 界面 时 不 能 只 考虑 最 新 的 浏览 器 一 样 ， 设 计 应 用 时 也 不 能 只 考虑 最 
新 一 代 移 动 网 络 。 如 前 所 述 (7.1.7 节 )， 即 便 用 户 手 里 拿 着 最 新 的 手机 ， 也 需要 不 
断 在 4G、3G， 甚 至 2G 网 络 之 间 切 换 。 我 们 的 应 用 必须 接受 这 些 接口 变化 ， 作 出 相 
应 调整 。 









































1 在 浏览 器 中 ， 可 以 使 用 navigator .onLine 接收 连接 状态 通知 ， 也 可 以 利 

ne , 用 NetInfo (Network Information API， 网 络 信 息 API) 查询 和 监听 连接 属 

一 4 性 的 变化 。 要 了 解 更 多 信息 ， 请 参考 Paul Kinlan 在 HTML5 Rocks 上 的 文 
章 : Working Off the Grid with HTMLS Offline (http:/hpbn.co/offline ) 。 





移动 网 络 中 不 变 的 只 有 变化 。 距 离 信 号 塔 的 远近 、 活 跃 用 户 的 多 少 、 环 境 冲 突 、 一 
天 中 的 时 段 ， 以 及 其 他 很 多 不 可 预知 的 因素 ， 都 会 导致 移动 信道 质量 的 差异 。 明 白 
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了 这 些 ， 你 就 会 知道 为 优化 移动 应 用 而 对 各 种 带宽 和 延迟 所 作 的 估算 结果 ， 最 多 就 
是 一 种 瞬 态 数据 点 。 





要 
信 丰 
上 4 

















iPhone 4 的 “天 线 门 ”是 无 法 准确 预测 无 线性 能 的 一 个 典型 事例 : 信号 质 
心 量 会 受到 你 担 持 手 机 的 手 与 天 线 距 离 的 影响 。 你 拿手 机 的 姿势 不 对 ”这 句 
流行 语 正 是 由 此 而 来 。 

















移动 网 络 的 延迟 和 带宽 估计 值 基本 上 就 是 几 十 或 几 百 ms， 最 多 1 s。 实 际 上 ， 虽然 
6.4.2 节 中 “ 自 适 应 比特 流 ” 那 一 部 分 介绍 的 优化 策略 ， 即 将 数据 分 成 多 个 几 秒 钟 的 
块 ， 对 持久 数据 流 (比如 视频 ) 还 是 有 用 的 ， 但 对 带宽 的 估计 值 绝对 不 该 缓存 ， 或 
者 用 于 决定 将 来 的 吞吐 量 ， 就 算是 对 4G 网 络 也 不 行 ! 可 能 你 刚刚 测量 的 速度 是 几 
百 Kbits， 而 换 了 只 手 速度 就 到 了 Mbit/s 以 上 。 





移动 网 络 中 的 流 媒 体 应 用 


流 媒 体 应 用 在 移动 网 络 中 是 一 个 难题 。 如 果 你 需要 一 次 长 时 间 的 下 载 ， 而 且 知 道 
要 用 到 整个 文件 ， 就 应 该 一 次 性 下 载 该 文件 ， 然 后 让 无 线 模块 尽量 空闲 更 长 时 间 。 
前 面 介绍 的 Pandora 应 用 中 下 载 音 乐 文件 的 例子 就 是 一 个 典型 。 


可 是 ， 如 果 由 于 文件 太 大 ， 或 用 户 行为 受 限 ， 不 能 一 次 性 下 载 完 整 的 文件 〈 比 如 
高 清 视频 ) ， 那 就 应 该 利用 6.4.2 节 中 “ 自 适 应 比特 流 ” 那 一 部 分 介绍 的 优化 策略 ， 
适应 网 络 吞 吐 量 的 不 断 变化 。 此 时 ， 电 池 耗 电 可 能 更 快 ， 但 至 少 你 能 保证 最 佳 用 
户 体验 ! 当然 ， 也 可 以 建议 用 户 切 换 到 Wi-Fi 网 络 。 











在 任何 网 络 中 ， 要 估计 端 到 端的 带宽 和 延迟 都 很 难 ， 移 动 网 络 尤 其 。 可 以 说 ， 你 的 
估计 十 有 八 九 都 不 靠 谱 。 相 反 ， 应 该 基于 相关 网 络 属于 哪 一 代 的 粗 粒度 信息 ， 相 应 
地 调整 代码 。 记 住 ， 知 道 移动 网 络 属于 哪 一 代 或 者 是 什么 类 型 ， 不 能 保证 任何 端 到 
端的 性 能 ， 但 你 却 能 知道 无 线 网 络 第 一 跳 的 延迟 数据 ， 以 及 运营 商 网 络 中 端 到 端的 
数据 。 这 一 块 的 详细 信息 ， 请 参考 7.5.1 节 中 的 “移动 网 络 中 的 延迟 与 抖动 ”， 以 及 
表 7-6。 


最 后 ， 除 了 吞吐 量 和 延迟 之 外 ， 还 应 该 考虑 连接 中 断 。 要 把 连接 中 断 作 为 常态 ， 而 
不 是 例外 。 不 管 网 络 是 不 是 可 用 ， 你 的 应 用 都 应 该 尽量 保持 运行 ， 而 且 应 该 根据 请 
求 类 型 和 特定 的 问题 作出 反应 : 

。 不 要 缓存 或 试图 猜测 网 络 状态 ， 

。 调度 请 求 、 监 听 并 诊断 错误 ， 

。 瞬 态 错误 总 会 发 生 ， 不 可 忽视 ， 可 以 采取 重 试 策略 ， 
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。 监听 连接 状态 ， 以 便 采 用 最 佳 请 求 方式 ; 

。 对 重 试 请 求 采用 补 傍 算 法 ， 不 要 永远 循环 ， 

。 离线 时 ， 尽 可 能 记录 并 在 将 来 发 送 请 求 ， 

。 利用 HTML5 的 AppCache 和 1localStorage 实现 离线 应 用 。 





5 


: 随 着 HetNet 越 来 越 多 地 得 到 部 署 ， 转 换 小 区 的 频率 将 大 幅 上 升 ， 监 控 连 接 
4 4 、 状 态 和 类 型 只 会 变 得 更 加 重要 。 不 过 也 有 一 个 好 消息 ， 即 较 小 的 小 区 也 应 
由 ， 该 提供 较 理想 的 总 体 吞吐 量 和 延迟 时 间 。 


8.5 ”爆发 传输 数据 并 转 为 空闲 


移动 无 线 接口 专门 为 爆发 性 传输 做 过 优化 ， 这 一 点 应 该 尽 可 能 利用 。 比 如 ， 把 请 求 
分 组 ， 尽 可 能 多 和 快 地 下 载 数 据 ， 然 后 让 无 线 模 块 转 为 空间 。 这 样 ， 既 可 以 获得 最 
大 的 网 络 吞 吐 量 ， 也 能 节约 电量 。 




















寻 全 
， 





估算 网 络 速度 唯一 正确 的 方式 ， 就 是 使 用 它 ! LTE 和 HSPA+ 等 最 新 一 代 
。 网 络 ， 每 隔 1 ms 就 会 动态 分 配 一 次 资源 ， 而 且 更 适合 爆发 性 的 数据 传输 。 
全 换 句 话说 ， 要 想 快 ， 就 要 简单 ， 批量 请 求 ， 预 先 下 载 尽 可 能 多 的 数据 ， 然 
后 让 网 络 空闲 。 


























基于 此 ， 一 个 重要 的 结论 就 是 : 渐进 加 载 资源 在 移动 网 络 中 次 大 于 利 。 每 次 只 下 载 
一 点 数据 会 导致 应 用 的 吞吐 量 和 延迟 都 摇摆 不 定 ， 同 时 消耗 的 电量 可 能 也 会 更 多 。 
因此 ， 要 尽 可 能 预先 下 载 数据 ， 预 测 用 户 接 下 来 可 能 需要 看 什么 ， 提 前 下 载 ， 尽 量 
让 无 线 模块 空闲 : 


。 如 果 需 要 大 型 音频 或 视频 文件 ， 考 虑 提前 下 载 整个 文件 ， 而 不 要 以 比特 为 单位 地 
流 式 下 载 ， 

。 预先 取得 应 用 内 容 ， 通 过 测量 和 统计 工具 来 辨别 什么 内 容 适 合 提 前 下 载 ; 

。 预先 取得 第 三 方 内 容 ， 比 如 广告 ， 通 过 应 用 逻辑 提前 显示 并 更 新 它们 的 状态 ; 

。 人 允许 设 备 关 闭 无 线 模块 ,保持 其 空闲 ,不 要 忘 了 优化 和 消除 间歇 性 传输 (参见 7.3.5 
市 中 的 “46% 的 电量 消耗 仅 传输 0.2% 的 数据 ”) 。 























构建 和 评估 预 取 模型 


预 取 内 容 总 会 存在 矛盾 : 一 方面 ， 你 希望 尽 可 能 下 载 更 少 的 数据 ， 另 一 方面 ， 你 
又 想 减 少 延 迟 和 吞吐 量 的 变动 ， 同 时 降低 对 电池 的 影响 。 哪 一 方面 更 重要 呢 ? 这 
样 问 本 身 就 是 错误 的 。 答 案 永 远 与 应 用 的 具体 使 用 情境 ， 以 及 你 选择 用 来 评估 预 
取 策 略 有 效 性 的 指标 相关 。 











重点 在 哪里 ? 最 低 限 度 ， 要 做 到 三 个 变量 的 平衡 : 传输 的 字 节 数 、 对 电池 的 影响 ， 
还 有 网 络 吞 吐 量 及 延迟 的 变动 。 而 有 全， 如 前 所 述 ， 这 三 个 变量 并 不 相互 排斥 。 一 
次 下 载 较 多 字 节 可 能 会 带 来 更 大 的 吞吐 量 ! 

对 于 能 准确 预测 使 用 模式 的 应 用 ， 可 以 采取 激进 的 预 取 策略 ， 将 电量 消耗 降 到 最 
低 ， 提 升 用 户 体 验 ， 同 时 避免 大 下 载 量 的 开销 。 相 反 ， 不 够 好 的 预 取 策略 可 能 会 
下 载 大 量 不 必要 的 数据 ， 降 低 整 体 用 户 体验 。 

要 确定 应 用 的 具体 行为 ， 首 先 要 确定 你 的 主要 目标 ， 以 及 应 用 的 主要 使 用 模式 。 
然后 ， 根 据 这 些 因 素 决 定 预 取 策略 ， 并 收集 数据 以 验证 你 的 预测 ， 如 此 反复 。 


8.6 ”把 负载 转移 到 Wi-Fi 网 络 


目前 的 行业 预测 显示 ， 世 界 范围 内 几乎 90% 的 无 线 流 量 都 源 自 室 内 ， 而 且 经 常 是 
在 有 Wi-Fi 连接 的 区 域内 。 虽 然 最 新 4G 网 络 的 峰值 吞吐 量 和 延迟 时 间 都 与 Wi-Fi 
不 相 上 下 ,但 每 月 的 数据 流量 往往 都 有 上 限 ， 毕 莞 移动 上 网 是 按 量 计 费 的 ， 价 格 
并 不 便宜 。 另 外 ，Wi-Fi 连接 下 的 大 数据 量 传输 更 省 电 (参见 7.3.1 节 “3G、4G 和 
Wi-Fi 对 电源 的 要 求 ”)， 也 不 需要 RRC。 


可 能 的 情况 下 ， 特 别 是 对 需要 处 理 较 大 数据 量 的 应 用 ， 都 应 该 利用 Wi-Fi 连接 。 如 
果 检 测 不 到 Wi-Fi 连接 ， 可 以 建议 用 户 打 开 Wi-Fi 连接 ， 以 提升 体验 和 节省 电量 。 


8.7 ”遵从 协议 和 应 用 最 佳 实践 

网 络 基 础 设施 的 分 层 架 构 有 一 个 最 大 的 优点 ， 那 就 是 把 物理 交付 接口 从 传输 层 中 
抽象 了 出 来 ， 而 传输 层 又 把 路 由 和 数据 交付 从 应 用 协议 中 抽象 了 出 来 。 这 种 分 离 
的 结果 就 是 API 具有 独立 性 ， 但 为 了 取得 端 到 端的 最 佳 性 能 ， 我 们 仍然 要 考虑 整 


个 架构 。 


本 章 主 要 讨论 了 移动 网 络 物 理 层 的 独立 性 能 ， 比 如 RRC 的 存在 、 电 池 使 用 时 间 的 问 
题 ， 以 及 移动 网 络 中 独 有 的 路 由 延迟 。 在 物理 层 之 上 ， 是 我 们 前 几 章 已 经 介绍 过 的 
传输 和 会 话 协 议 ， 针 对 它们 的 优化 同样 甚至 更 加 重要 : 

。 2.5 节 “ 针 对 TCP 的 优化 建议 ”; 

。 3.3 节 “ 针 对 UDP 的 优化 建议 ”; 

。 4.7 节 “ 针 对 TLS 的 优化 建议 ”。 

通过 重用 持久 连接 、 将 服务 器 和 数据 部 署 到 离 客 户 端 更 近 的 地 方 、 优 化 TLS 部 署 ， 
以 及 其 他 所 有 优化 措施 ， 对 移动 网 络 而 言 只 会 更 加 重要 ， 因 为 移动 网 络 的 往返 时 间 
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长 ， 而 带宽 永远 都 很 昂贵 。 


当然 ， 我 们 的 优化 策略 并 不 会 止步 于 传输 和 会 话 协议 ， 这 两 方面 只 是 基础 。 从 现在 
开始 ， 我 们 还 必须 考虑 不 同 应 用 协议 (HTTP 1.0、1.1 和 2.0)， 以 及 通用 Web 应 用 
开发 最 佳 实践 对 性 能 的 影响 。 继 续 阅 读 吧 ， 还 没有 结束 呢 ! 








第 三 部 分 





HTTP 


第 9 章 


HTTP 简 史 





HTTP (HyperText Transfer Protocol， 超 文本 传输 协议 ) 是 互联 网 上 最 普遍 采用 的 一 
种 应 用 协议 ， 也 是 客户 端 与 服务 器 之 间 的 共用 语言 ， 是 现代 Web 的 基础 。 从 最 初 的 
一 个 关键 字 和 文档 路 径 开 始 ，HTTP 最 终 不 仅 成 为 了 浏览 器 的 协议 ， 而 且 也 几乎 成 
为 了 所 有 互联 网 软件 和 硬件 应 用 的 协议 。 


本 章 将 简略 回顾 一 下 HTTP 协议 的 发 展 史 。 全 面 探讨 HTTP 的 各 种 语义 不 是 本 书 
的 意图 ， 但 理解 HTTP 在 设计 上 的 关键 转变 ， 以 及 每 次 转变 背后 的 动机 一 一 特别 是 
HTTP 2.0 将 带 来 的 很 多 改进 ， 对 我 们 讨论 HTTP 性 能 则 至 关 重 要 。 


ZC— ‘ 
9.1 HTTP 0.9: 只 有 一 行 的 协议 
Tim Berners-Lee 最 初 的 HTTP 建议 是 以 简洁 为 出 发 点 设计 的 ， 目 的 是 推动 他 的 另 一 
个 刚刚 朝 节 的 思想 一 一 万 维 网 的 应 用 。 事 实证 明 ， 这 个 策略 韭 常 有 效 。 这 个 经 验 也 
非常 值得 有 抱负 的 协议 设计 者 汲取 。 


1991 年 ，Tim Berners-Lee 概述 了 这 个 新 协议 的 动机 ， 并 有 罗列 了 几 条 安 观 的 设计 目 
标 : 支持 文件 传输 、 能 够 请 求 对 超 文本 文档 的 索引 搜索 、 格 式 化 协商 机 制 ， 以 及 能 
够 把 客户 端 引 导 有 至 不 同 的 服务 器 。 为 了 实际 验证 这 个 理论 ， 他 构建 了 一 个 简单 的 原 
型 ， 实 现 了 建议 的 部 分 功能 : 




















。 客户 端 请 求 是 一 个 ASCII 字符 串 ， 
。 客户 端 请 求 由 一 个 回 车 符 (CRLF) 结尾 ; 
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。 服务 器 响应 是 一 个 ASCII 字符 流 ; 
。 服务 器 响应 的 是 一 种 超 文本 标记 语言 (HTML ) ; 
。 连接 在 文档 传输 完毕 后 断 开 。 


然而 ， 即 便 这 样 说 也 比 实际 情况 复杂 。 以 上 规则 定义 了 一 个 极其 人 简单、 可 以 通过 
Telnet 验证 的 协议 ， 某 些 Web 浏览 器 直到 今天 仍然 支持 : 





$> telnet google.com 80 
Connected to 74.125.XXxXx.XXX 
GET /about/ 


( 超 文本 响应 ) 

(连接 关闭 ) 
请 求 只 有 一 行 ， 包 括 GET 方法 和 要 请 求 的 文档 的 路 径 。 响 应 是 一 个 超 文 本 文档 ， 没 
有 首部 ， 也 没有 其 他 元 数据 ， 只 有 HTML。 这 实在 是 简单 得 不 能 再 简单 了 ! 鉴于 以 
上 交互 行为 只 实现 了 部 分 预期 目标 ， 因 此 相应 的 协议 也 被 非 官方 地 称 为 HITP 0.9。 
此 后 发 生 的 事 ， 大 家 都 知道 了 。 


以 1991 年 这 个 低调 开端 为 起 点 ，HTTP 在 随后 几 年 中 展现 了 自己 的 生命 力 ， 得 到 了 
迅速 发 展 。 下 面 我 们 简单 总 结 一 下 HTTP 0.9 的 功能 : 


。 客户 端 / 服 务 器 、 请 求 /响应 协议 ; 

。 ASCII 协议 ， 运行 于 TCP/IP 链接 之 上 ; 

。 设计 用 来 传输 超 文 本 文档 (HTML) ; 

。 服务 器 与 客户 端 之 间 的 连接 在 每 次 请 求 之 后 都 会 关闭 。 

















Apache 和 Nginx 等 流行 的 Web 服务 器 至 今 仍然 支持 HITP 0.9， 部 分 原 

心 。 因 是 支持 它 不 费 什 么 事 儿 ! 如 果 你 感到 好 奇 ， 可 以 打开 Telnet 终端 ， 通 过 

”HTTP 0.9 访问 google.com 或 其 他 你 熟悉 的 网 站 ， 观 察 一 下 这 个 早期 协议 
的 行为 和 局 限 性 。 









































9.2 HTTP 1.0: 迅速 发 展 及 参考 性 RFC 

1991 年 到 1995 年 ，HTML 规范 和 一 种 新 型 的 名 叫 “Web 浏览 器 ”的 软件 都 获得 了 
快速 发 展 。 与 此 同时 ， 面 向 消费 者 的 公共 互联 网 基础 设施 ， 也 日 渐 兴 起 并 迅速 发 展 
起 来 。 








完美 风暴 : 1990 年 代 初 期 互联 网 的 繁荣 


在 Tim Berner-Lee 最 初 提出 的 浏览 器 原型 基础 上 , NCSA (National Center of 
Supercomputer Applications， 美 家 超级 计算 机 应 用 中 心 ) 决定 实现 自己 的 
有 版本。 于 是 ， 世 界 上 第 一 款 流行 的 浏览 器 NSCA Mosaic 诞生 了 。1994 年 10 
月 ，NCSA 浏览 器 开发 团队 中 的 一 员 Marc Andreessen， 与 Jim Clark 合伙 创建 了 
Mosaic Communications 公司 。 这 家 公司 后 来 改名 为 Netscape， 并 于 1994 年 12 月 
开始 销售 Netscape Navigator 1.0。 此 时 此 刻 ， 万维网 已 经 在 学 术 研 究 领 域 之 外 迈 出 
很 大 步伐 。 

事实 上 ， 主 导 成 立 万 维 网 联盟 (W3C) 的 CERN (Conseil Européen pour la Recherche 
Nucléaire， 欧 洲 核子 研究 委员 会 ) 也 在 1994 年 组 织 召 开 了 第 一 届 万 维 网 大 会 。 而 
IETF (Internet Engineering Task Force， 互 联网 工程 任务 组 ) 也 成 立 了 HTTP 工作 
组 (HTTP-WG) ， 和 致力 于 改进 HTTP 协议 。 从 那 时 起 ， 这 两 个 组 织 就 对 万 维 网 的 
发 展开 始 发 挥 作用 ， 而 且 今 后 还 将 继续 担当 这 一 角色 。 


同样 在 1994~1995 年 ，CompuServe、AOL 和 Prodigy 也 开始 提供 拨号 上 网 服务 。 
于 是 ， 学 术 界 和 产业 界 合作 演绎 了 一 场 “ 完 美 风暴 "”。 就 在 这 一 波 互 联网 浪潮 的 基 
础 上 ，Netscape 的 IPO 于 1995 年 8 月 9 日 获得 了 历史 性 成 功 。 互 联网 火 了 ， 每 个 
人 都 想 从 中 分 一 杯 和 次。 











随 着 人 们 对 新 兴 Web 的 需求 越 来 越 多 ， 以 及 它们 在 公共 Web 上 的 应 用 迅速 爆发 ， 
HTTP 0.9 的 很 多 根本 性 不 足 便 暴 露出 来 。 人 们 需要 一 种 协议 ， 它 不 仅 能 访问 超 文本 
文档 ， 还 能 提供 有 关 请 求 和 响应 的 各 种 元 数据 ， 而 且 要 支持 内 容 协商 ， 等 等 。 相 应 
地 ， 新 兴 的 Web 开发 者 社区 为 满足 这 些 需 求 ， 推 出 了 大 量 实验 性 的 HTTP 服务 器 和 
客户 端 实 现 ， 基 本 上 遵循 实现 、 部 署 、 推 广 采 用 的 流程 。 

就 在 这 些 实验 性 开发 的 基础 上 ， 出 现 了 一 套 最 佳 实践 和 共用 模式 。 于 是 ，1996 年 ， 
HTTP 工作 组 发 布 了 RFC 1945， 解 释 说 明了 当时 很 多 HITP 1.0 实现 的 “公共 用 
法 ”。 不 过 ， 据 我 们 所 知 ， 这 个 RFC 只 是 参考 性 的 。HTTP 1.0 并 不 是 一 个 正式 的 规 
范 或 互联 网 标准 ! 


不 管 怎 样 ，HTTP 1.0 的 请 求 对 我 们 而 言 应 该 是 非常 熟悉 的 : 














$> telnet website.org 80 

Connected to XXX.XXxX.XXX.XXX 

GET /rfc/rfc1945.txt HTTP/1.0 © 

User-Agent: CERN-LineMode/2.15 libwww/2.17b3 


Accept: */* 


HTTP/1.0 200 OK 名 
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Content-Type: text/plain 

Content-Length: 137582 

Expires: Thyu, 01 Dec 1997 16:00:00 GMT 
Last-Modified: Wed, 1 May 1996 12:45:26 GMT 
Server: Apache 0.84 


( 纯 文本 响应 ) 

连接 关闭 ) 

@ 请 求 行 中 包含 HTTP 版 本 号 ， 随 后 是 请 求 首 部 
@ 响应 状态 ， 后 跟 响 应 首部 


上 面 列 出 的 交换 信息 并 未 展示 出 HTTP 1.0 的 所 有 功能 ， 但 却 能 说 明 该 协议 的 关键 


变化 : 


。 请 求 可 以 由 于 多 行 首部 字段 构成 ， 

。 响应 对 象 前 面 添 加 了 一 个 响应 状态 行 ; 

。 响应 对 象 也 有 自己 的 由 换行 符 分 隔 的 首部 字段 ， 

。 响应 对 象 不 局 限于 超 文 本 ， 

。 服务 器 与 客户 端 之 间 的 连接 在 每 次 请 求 之 后 都 会 关闭 。 


请 求 和 响应 首部 都 使 用 ASCII 编码 ， 但 响应 对 象 本 身 可 以 是 任何 类 型 : HTML 文 
件 、 纯 文本 文件 、 图 片 ， 或 其 他 内 容 类 型 。 事 实 上 ，HTTP 中 的 “HTT” (Hypertext 
Transfer， 超 文本 传输 ) 在 协议 出 现 后 不 久 就 已 经 用 词 不 当 了 。 在 实践 中 ，HTTP 迅 
速 发 展 为 超 媒 体 传输 协议 ， 但 最 初 的 名 字 则 沿用 至 今 。 


除了 媒体 类 型 协商 ，RFC 还 解释 了 很 多 已 经 被 实现 的 其 他 功能 : 内 容 编 码 、 字 符 集 
支持 、 多 部 分 类 型 、 认 证 、 缓 存 、 代 理 行 为 、 日 期 格式 ， 等 等 。 





一 、 

















今天 ， 几 乎 所 有 Web 服务 器 都 支持 ， 而 且 以 后 还 会 继续 支持 HTTP 1.0。 除 
4 4 、 此 之 外 ， 剩 下 的 你 都 知道 了 。 但 HTTP 1.0 对 每 个 请 求 都 打开 一 个 新 TCP 
”连接 严重 影响 性 能 ， 这 一 点 可 以 参考 2.1 节 “ 三 次 握手 ”和 2.2.2 市 “ 慢 启 
动 ”。 




















9.3 HTTP 1.1: 互联 网 标准 


将 HTTP 转 为 IETF 正式 互联 网 标准 的 工作 ， 与 通过 RFC 1945 说 明 解 释 HTTP 1.0 
是 并 行 展开 的 ， 从 1995 年 到 1999 年 ， 大 致 经 历 了 4 年 时 间 。 事 实 上 ， 就 在 HTTP 
1.0 发 布 大 约 6 个 月 之 后 ， 也 就 是 1997 年 1 月， 定义 正式 HITP 1.1 标准 的 RFC 
2068 也 发 布 了 。 又 过 了 两 年 半 ， 即 到 了 1999 年 6 月 RFC 2616 发 布 ， 又 在 标准 中 
集合 了 很 多 改进 和 更 新 。 
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HTTP 1.1 标准 厘清 了 之 前 版 本 中 很 多 有 歧义 的 地 方 ， 而 且 还 加 入 了 很 多 重要 的 性 能 


优 
求 


有 











七 : 持久 连接 、 分 块 编码 传输 、 字 而 范围 请 求 、 增 强 的 缓存 机 制 、 传 输 编码 及 请 
管道 。 
了 这 些 新 功能 ， 我 们 就 可 以 像 任何 当前 的 HTTP 浏览 器 和 客户 端 一 样 检视 HTTP 


1.1 会 话 : 


$> telnet website.org 80 
Connected to xxx.XxXxX.xXxXx.xXxx 


GET /index.htmL HTTP/1.1 © 

Host: website.org 

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4)... (snip) 
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 
Accept-Encoding: gzip,deflate,sdch 

Accept-Language: en-US,en;q=0.8 

Accept-Charset: 1IS0-8859-1,utf-8;q=0.7,*;q=0.3 

Cookie: __qca=PO-800083390... (snip) 


HTTP/1.1 200 OK 名 

Server: nginx/1.0.11 

Connection: keep-alive 

Content-Type: text/html; charset=utf-8 
Via: HTTP/1.1 GWA 

Date: Wed, 25 Jul 2012 20:23:35 GMT 
Expires: Wed, 25 Jul 2012 20:23:35 GMT 
Cache-Control: max-age=0, no-cache 
Transfer-Encoding: chunked 


100 © 


<!doctype htmL> 
(snip) 


100 
(snip) 


o@ 


GET /favicon.ico HTTP/1.1 © 

Host: www.website.org 

User-Agent: Mozilla/5.0 (Macintosh; InteL Mac OS X 10 7_4)... (snip) 
Accept: */* 

Referer: http://website.org/ 

Connection: close @ 

Accept-Encoding: gzip,deflate,sdch 

Accept-Language: en-US,en;q=0.8 

Accept-Charset: 1IS0-8859-1,utf-8;q=0.7,*;q=0.3 

Cookie: __qca=PO-800083390... (snip) 


HTTP/1.1 200 OK @ 
Server: nginx/1.0.11 
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Content-Type: image/x-icon 

Content-Length: 3638 

Connection: close 

Last-Modified: Thu, 19 JuL 2012 17:51:44 GMT 
Cache-Control: max-age=315360000 
Accept-Ranges: bytes 

Via: HTTP/1.1 GWA 

Date: Sat, 21 Jul 2012 21:35:22 GMT 

Expires: Thu, 31 Dec 2037 23:55:55 GMT 

Etag: W/PSA-GAu260XbDi 


(图 标 数 据 ) 
(关闭 连接 ) 
@ 请 求 HTML 文件 ， 及 其 编码 、 字 符 集 和 元 数据 
@ 对 原始 HTML 请 求 的 分 块 响应 
@ 以 ASCII 十 六 进 制 数字 表 示 的 分 块 数据 的 字 节 数 (256 字 节 ) 
@@ 分 基数 据 流 响 应 结束 
@ 在 同一 个 TCP 连接 上 请 求 图 标 文件 
@ 通知 服务 器 不 再 使 用 连接 了 
@ 图 标 响应 ， 随 后 关闭 连接 


啊 ， 这 一 次 可 复杂 多 了 。 首 先 ， 最 明显 的 差别 是 这 里 发 送 了 两 次 对 象 请 求 ， 一 次 请 
求 HTML 页 面 ， 一 次 请 求 图 片 ， 这 两 次 请 求 都 是 通过 一 个 连接 完成 的 。 这 个 连接 是 
持久 的 ， 因 而 可 以 重用 TCP 连接 对 同一 主机 发 送 多 次 请 求 ， 从 而 实现 更 快 的 用 户 体 
验 ， 参见 2.5 节 “ 针 对 TCP 的 优化 建议 ”。 


























为 终止 持久 连接 ， 客 户 端 的 第 二 次 请 求 通过 connection 首部 ， 向 服务 器 明确 发 送 
了 关闭 令 牌 。 类 似 地 ， 服 务 器 也 可 以 在 响应 完成 后 ， 通 知客 户 端 自 己 想 要 关闭 当前 
TCP 连接 。 从 技术 角度 讲 ， 不 发 送 这 个 令 牌 ， 任 何 一 端 也 可 以 终止 TCP 连接 。 但 为 
确保 更 好 地 重用 连接 ， 客 户 端 和 服务 器 都 应 该 尽 可 能 提供 这 个 信息 。 

















硅 全 


Ey HTTP 1.1 改变 了 HTTP 协议 的 语义 ， 上 默认 使 用 持久 连接 。 换 句 话说 ， 除 
CA 
MY 





。 非 明确 告知 (通过 Connection: close 首部 ) ， 否 则 服务 器 默认 会 保持 连 
心 ' 接 打 开 。 
不 过 ， 这 个 功能 也 反 向 移植 到 了 HTTP 1.0， 可 以 通过 Connection: Keep- 
Alive 首部 来 启用 。 实 际 上 ， 如 果 你 使 用 的 是 HTTP 1.1， 从 技术 上 说 不 需 
要 Connection: Keep-Alive 首部 ， 但 很 多 客户 端 还 是 选择 加 上 它 。 























此 外 ，HTTP 1.1 协议 汪 、 加 了 内 容 、 编 码 、 字 符 集 ， 甚 至 语言 的 协商 机 制 ， 还 添加 了 
传输 编码 、 缓 存 指令 、 客 户 端 cookie 等 十 几 个 可 以 每 次 请 求 都 协商 的 字段 。 





我 们 不 打算 细 究 HTTP 1.1 的 每 个 功能 ， 这 需要 一 本 书 才 行 ， 而且 已 经 有 很 多 这 方 
面 的 好 书 了 。 相 反 ， 上 面 的 例子 只 是 为 了 说 明 HTTP 的 发 展 有 多 快 ， 以 及 客户 端 与 
服务 器 每 次 交换 数据 有 多 复杂 。 








要 详细 了 解 HITP 协议 的 内 部 工作 原理 ， 请 参考 David Gourley 和 Brian 


4 4 。Totty 合 著 的 《HTTP 权威 指南 》。 
0 








9.4 HTTP 2.0: 改进 传输 性 能 


RFC 2616 自发 布 以 来 ， 一 直 都 是 互联 网 大 发 展 的 基石 。 几 十 亿 大 大 小 小 、 形 形 色色 
的 设备 ， 包 括 桌面 计算 机 和 手机 ， 每 天 都 在 通过 HTTP 通信 传输 新 闻 、 视 频 ， 还 有 
数 以 百 万 计 的 Web 应用， 它们 已 经 成 为 我 们 日 常生 活 不 可 或 缺 的 部 分 。 


曾经 以 简单 的 理念 开始 ， 只 有 一 行 的 用 于 取得 超 文 本 的 协议 ， 迅 速 发 展 为 通用 的 超 
媒体 传输 机 制 。 十 几 年 后 的 今天 ，HTTP 已 经 成 为 可 以 在 任何 领域 使 用 的 核心 协议 。 
无 所 不 在 的 支持 这 个 协议 的 服务 器 ， 以 及 随处 可 见 的 访问 这 些 服务 器 的 客户 端 ， 都 
意味 着 在 HTTP 之 上 ， 人 们 正在 设计 和 部 署 更 多 的 应 用 。 


需要 一 个 协议 来 控制 你 的 咖啡 壶 吗 ? RFC 2324 就 是 “ 超 文 本 咖啡 过 控制 协议 ” 
(Hyper Text Coffee Pot Control Protocol，HTCPCP/1.0) ， 它 是 IETF 愚人 节 的 一 个 
笑话 。 但 在 全 新 的 物 联网 时 代 ， 这 种 事 将 会 越 来 越 多 地 变 为 现实 。 








HTTP (Hypertext Transfer Protocol) 是 一 个 应 用 层 协议 ， 可 用 于 分 布 协作 式 
的 超 媒体 系统 。 它 是 一 个 通用 、 无 状态 的 协议 。 除 了 超 文 本 ， 通 过 扩展 它 的 
请 求 方式 、 错 误 编 码 及 首部 ， 还 可 以 将 它 用 于 很 多 其 他 领域 ， 比 如 域名 服务 
器 和 分 布 式 对 象 管理 系统 。HTTP 的 一 个 功能 就 是 允许 数据 的 类 型 变化 和 协 
商 ， 从 而 允许 系统 独立 于 被 传输 的 数据 构建 。 
一 一 RFC 2616: HTTP/1.1 (1999 年 6 月 ) 
HTTP 的 简单 本 质 是 它 最 初 得 以 采用 和 后 来 快速 发 展 的 关键 。 事 实 上 ， 很 多 舱 入 式 设 
备 ， 比 如 传感器 、 致 动 器 ， 甚 至 咖啡 索 ， 都 在 使 用 HTTP 作为 主要 的 控制 和 数据 协 
议 。 然 而 ， 在 巨大 成 功 的 压力 之 下 ， 同 时 随 着 我 们 越 来 越 多 地 把 应 用 (社交 媒体 、 电 
子 邮 件 、 新 闻 和 视频 ， 以 及 个 人 的 生活 与 工作 内 容 ) 部 署 到 Web 上 ，HTTP 的 问题 
也 出 现 了 。 今 天， 用 户 和 Web 开发 者 都 迫切 想 要 通过 HTTP 1.1 达到 一 种 几 近 实时 的 
响应 速度 和 协议 性 能 ， 而 要 请 足 这 个 需求 ， 仅 靠 在 原 协 议 基 础 上 修 修补 补 是 不 够 的 。 


为 应 对 这 些 新 挑 成 ，HTTP 必须 继续 发 展 。HTTP 工作 组 已 经 在 2012 年 宣布 要 开发 
HTTP 2.0， 
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当前 ， 出 现 了 一 种 保持 HTTP 语义， 但 脱离 HTTP/1.x 消息 分 帧 及 语法 的 协 

议 用 法 。 这 种 用 法 被 证 明 有 碍 于 性 能 ， 并 且 是 在 鼓励 滥用 底层 传输 协议 。 

本 工作 组 将 制定 一 个 新 规范 ， 从 有 序 、 半 双 工 流 的 角度 重新 表达 当前 HTTP 

的 语义 。 与 HTTP/1.x 一 样 ， 主 要 将 使 用 TCP 作为 传输 层 ， 不 过 也 应 该 支持 

其 他 传输 协议 。 

一 一 HTTP 2.0 纲领 (2012 年 1 月 ) 

HTTP 2.0 的 主要 目标 是 改进 传输 性 能 ， 实 现 低 延 迟 和 高 吞吐 量 。 主 版 本 号 的 增加 听 
起 来 像 是 要 做 大 的 改进 ， 从 性 能 角度 说 的 确 如 此 。 但 从 另 一 方面 看 ，HTTP 的 高 层 
协议 语义 并 不 会 因为 这 次 版 本 升级 而 受 影 响 。 所 有 HTTP 首部 、 值 ， 以 及 它们 的 使 
用 场景 都 不 会 变 。 


现 有 的 任何 网 站 和 应 用 ， 无 需 做 任何 修改 都 可 以 在 HTTP 2.0 上 跑 起 来 。 换 名 话说， 
不 用 为 了 利用 HTTP 2.0 的 好 处 而 修改 标记 。HTTP 服务 器 必须 运行 HTTP 2.0 协议 ， 
但 大 部 分 用 户 都 不 会 因此 而 受到 影响 。 唯 一 的 不 同一 一 假如 HTTP 工作 组 的 目标 能 
够 达成 ， 就 应 该 是 我 们 的 应 用 能 够 以 更 低 的 延迟 和 更 高 的 网 络 连接 利用 率 交 付 ! 











明白 了 这 一 点 ， 我 们 就 不 会 盲目 冒进 了 。 在 了 解 HTTP 2.0 协议 的 新 功能 之 前 ， 还 
是 有 必要 先 了 解 一 下 在 当前 HTTP 1.1 基础 上 部 署 和 提升 性 能 的 最 佳 实践 。HTTP 
2.0 工作 组 的 进展 很 快 ， 但 即便 最 终 标准 已 经 完成 ， 在 可 见 的 未 来 ， 我 们 还 是 必须 支 
持 HTTP 1.1 客户 端 一 一 现实 一 点 说 ， 至 少 十 年 内 还 要 支持 。 
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在 任何 复杂 的 系统 中 ， 性 能 优化 的 4 
解 开 来 ， 弄 清楚 每 一 
析 了 一 些 个 别 网 络 组 件 (不 同 的 物 


更 宏观 的 Web 性 能 优化 : 


。 延迟 和 带宽 对 Web 性 能 的 影响 ; 


Web 性 能 要 点 


恨 大 一 部 分 工作 就 是 把 不 同 层 之 间 的 交互 过 程 分 


层次 交互 的 约束 和 限制 。 到 目前 为 止 ， 我 们 已 经 比较 详细 地 分 





交付 方式 和 传输 协议 ) 。 现 在 ， 我 们 把 目光 转向 


。 传输 协议 〈TCP) 对 HTTP 的 限制 ; 


。 HTTP 协议 自身 的 功能 和 缺陷 ， 
。 Web 应 用 的 发 展 趋势 及 性 能 需 


有 HERS 
。 浏览 器 


览 右 局 限 性 和 优化 思路 。 





求 ， 





优化 不 同 层 之 间 的 交互 与 解 一 组 方程 没有 什么 不 同 ， 因 为 不 同 层 之 间 总 是 相互 依赖 ， 
但 优化 方式 却 有 很 多 可 能 性 。 任 何 优 化 建议 和 最 佳 做 法 都 不 是 一 成 不 变 的 ， 涉 及 的 


ley 


每 个 要 素 都 是 动态 发 展 的 : 浏览 
功能 和 复杂 度 也 与 日 俱 增 。 

因此 ， 在 讨论 具体 的 最 佳 实践 之 前 
Web 应 用 ， 我 们 手 里 有 什么 工具 ， 
利 或 有 碍 ? 





器 越 来 越 快 、 用 户 上 网 条 件 不 断 改 善 、Web 应 用 的 


， 一 定 要 先 明 确 真正 的 问题 何在 : 什么 是 现代 
如 何 测 量 Web 性 能 ， 系 统 的 哪些 部 分 对 优化 有 
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10.1 超 文本 、 网 页 和 Web 应 用 


互联 网 在 过 去 儿 十 年 的 发 展 过 程 中 ， 至 少 带 给 了 我 们 三 种 体验 : 超 文本 文档 、 富 媒 
体 网 页 和 交互 式 Web 应 用 。 不 可 否认 ， 后 两 种 之 间 的 界限 有 时 候 对 用 户 来 说 很 模 
糊 ， 但 从 性 能 的 角度 看 ， 这 几 种 形式 都 要 求 我 们 在 讨论 问题 、 测 量 和 定义 性 能 时 采 
取 不 同 的 手段 。 


。 超 文本 文档 
万 维 网 就 起 源 于 超 文本 文档 ， 一 种 只 有 基本 格式 ， 但 支持 超 链 接 的 纯 文 本 文档 。 
按照 现代 眼光 来 看 ， 这 种 文档 或 许 没什么 值得 大 惊 小 怪 的 ， 但 它 验 证 了 万 维 网 的 
假设 、 前 景 及 巨大 的 实用 价值 。 





。 富 媒体 网 页 
HTML 工作 组 和 早期 的 浏览 器 开发 商 扩展 了 超 文 本 ， 使 其 支持 更 多 的 媒体 ， 如 图 
片 和 音频 ， 同 时 也 为 丰富 布局 增加 了 很 多 手段 。 网 页 时 代 到 来 了 ， 我 们 可 以 基于 
不 同 的 媒体 构建 可 见 的 页 面 布局 了 。 但 网 页 还 只 是 看 起 来 漂亮 ， 很 大 程度 上 没有 
交互 功能 ， 与 可 打印 的 页 面 没 有 区 别 。 





。 Web 应 用 
JavaScript 及 后 来 DHTML 和 Ajax 的 加 入 ， 再 一 次 革命 了 Web， 把 简单 的 网 页 
转换 成 了 交互 式 Web 应 用 。Web 应 用 可 以 在 浏览 器 中 直接 响应 用 户 操作 。 于 是 ， 
Outlook Web Access (IE5 中 的 xMLHTTP 就 诞生 于 这 个 应 用 ) 等 最 早 的 、 成 熟 的 浏 
览 器 应 用 出 现 ， 也 揭 开 了 脚本 、 样 式 表 和 标记 文档 之 间 复 杂 依 赖 的 新 时 代 。 


HTTP 0.9 会 话 由 一 个 文档 请 求 构 成 ， 这 对 于 取得 超 文 本 内 容 完 全 够 用 了 : 一 个 文 
档 、 一 个 TCP 连接 ， 然 后 关闭 连接 。 因 此 ， 提 升 性 能 就 是 围绕 短期 TCP 连接 优化 
一 次 HTTP 请 求 。 


富 媒体 网 页 的 出 现 改 变 了 这 个 局 面 ， 因 为 一 个 简单 的 文档 ， 变 成 了 文档 加 依赖 资 
源 。 因 此 ，HTTP 1.0 引入 了 HTTP 元 数据 的 表示 法 (首部 )，HTTP 1.1 又 加 入 了 各 
种 则 在 提升 性 能 的 机 制 ， 如 缓存 、 持 久 连 接 ， 等 等 。 事实 上 ， 多 TCP 连接 目前 仍然 
存在 ， 性 能 的 关键 指标 已 经 从 文档 加 载 时 间 ， 变 成 了 页 面 加 载 时 间 ， 常 简写 为 PLT 
(Page Load Time ) 。 




















PLT 的 简单 定义 就 是 :“ 浏 览 器 中 的 加 载 旋转 图 标 停止 旋转 的 时 间 。” 更 技 
人 4 、 术 的 定义 则 是 浏览 器 中 的 ontoad 事件 ， 这 个 事件 由 浏览 器 在 文档 及 其 所 
尾 ， 有 依赖 资源 (JavaScript、 图 片 ， 等 等 ) 下 载 完毕 时 触发 。 
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最 后 ，Web 应 用 把 网 页 的 简单 依赖 关系 (在 标签 中 使 用 媒体 作为 基本 内 容 的 补充 ) 
转换 成 了 复杂 的 依赖 关系 : 标记 定义 结构 、 样 式 表 定义 布局 ， 而 脚本 构建 最 终 的 交 
互 式 应 用 ， 响 应 用 户 输入 ， 并 在 交互 期 间 创建 样式 表 和 标记 。 


结果 ， 页 面 加 载 时 间 ， 这 个 一 直 以 来 衡量 Web 性 能 的 事实 标准 ， 作 为 一 个 性 能 基础 
也 越 来 越 显 得 不 够 了 。 我 们 不 再 是 构建 网 页 ， 而 是 在 构建 一 个 动态 、 交 互 的 Web 应 
用 。 除 了 测量 每 个 资源 及 整个 页 面 的 加 载 时 间 (PLT)， 还 要 回答 有 关 应 用 的 如 下 几 


个 问题 : 




















。 应 用 加 载 过程 中 的 里 程 碑 是 什么 ? 
。 用 户 第 一 次 交互 的 时 机 何在 ? 

。 什么 交互 应 该 吸引 用 户 参与 ? 

。 每 个 用 户 的 参与 及 转化 率 如 何 ? 


性 能 好 坏 及 优化 策略 成 功 与 否 ， 与 你 定义 应 用 的 特定 基准 和 条 件 ， 并 反复 测试 的 效 
果 直 接 相关 。 没 有 什么 比 得 上 应 用 特定 的 知识 和 测量 ， 在 关系 到 赢利 目标 和 商业 指 
标的 情况 下 更 是 如 此 。 














DOM、CSSOM 和 JavaScript 
前 所 说 的 “脚本 、 样 式 表 和 标记 文档 之 间 复 杂 依 赖 ” 到 底 指 什么 呢 ? 要 回答 这 个 
问题 ， 我 们 得 先 回 顾 一 下 浏览 器 架构 ， 了 解 一 下 解析 、 布 局 和 脚本 如 何 相互 配合 
在 屏幕 上 绘制 出 像素 来 (图 10-1) 。 




















10-1: 浏览 器 处 理 流水 线 : HTML、CSS 和 JavaScript 


浏览 器 在 解析 HTML 文档 的 基础 上 构建 DOM (Document Object Model， 文 档 
对 象 模型 )。 与 此 同时 ， 还 有 一 个 常常 被 忽略 的 模型 一 -CSSOM (CSS Object 
Model，CSS 对 象 模型 ) ， 也 会 基于 特定 的 样式 表 规 则 和 资源 构建 而 成 。 这 两 个 模 
型 共同 创建 “ 泻 染 树 "”， 之 后 浏览 器 就 有 了 足够 的 信息 去 进行 布局 ， 并 在 屏幕 上 绘 
制图 形 。 到 目前 为 止 ， 一 切 都 很 好 理解 。 
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然而 ， 此 时 不 得 不 提 到 我 们 最 大 的 朋友 和 祸害 : JavaScript。 脚 本 执行 过 程 中 可 能 
遇 到 一 个 同步 的 document.write， 从 而 阻塞 DOM 的 解析 和 构建 。 类 似 地 ， 脚 本 
也 可 能 查询 任何 对 象 的 计算 样式 ， 从 而 阻塞 CSS 处 理 。 结 果 ，DOM 及 CSSOM 
的 构建 频繁 地 交织 在 一 起 : DOM 构建 在 JavaScript 执行 完毕 前 无 法 进行 ， 而 
JavaScript 在 CSSOM 构建 完成 前 也 无 法 进行 。 

应 用 的 性 能 ， 特 别 是 首次 加 载 时 的 “ 泻 染 前 时 间 >， 直 接 取 决 于 标记 、 样 式 表 和 
JavaScript 这 三 者 之 间 的 依赖 关系 。 顺 便 说 一 各， 还 记得 流行 的 “样式 在 上 ， 脚 本 
在 下 ”的 最 佳 实践 吗 ? 现在 你 该 知道 为 什么 了 。 泻 染 和 脚本 执行 都 会 受 样式 表 的 
阻塞 ， 因 此 必须 让 CSS 以 最 快 的 速度 下 载 完 。 











10.2 剖析 现代 Web 应 用 


现代 Web 应 用 到 底 长 啥 样 ? HTTP Archive (http://httparchive.org/) 可 以 回答 这 个 问 
题 。 这 个 网 站 项 目 一 直 在 抓 取 世 界 上 是 热门 的 网 站 (Alexa 前 100 万 名 中 的 30 多 万 
名 )， 记 录 、 聚 合并 分 析 每 个 网 站 使 用 的 资源 、 内 容 类 型 、 首 部 及 其 他 元 数据 的 数量 。 


2013 年 初 ， 一 个 普通 的 Web 应 用 由 下 列 内 容 构 成 。 








。 90 个 请 求 ， 发 送 到 15 个 主机 ， 总 下 载 量 1311 KB 
+ HTML: 10 个 请 求 ，52 KB 
* 图 片 : 55 个 请 求 ，812 KB 
+ JavaScript: 15 个 请 求 ，216 KB 
+ CSS: 5 个 请 求 ，36 KB 
， 其 他 资源 : 5 个 请 求 ，195 KB 


在 你 读 到 这 里 的 时 候 ， 前 面 所 有 数字 都 会 变 大 〈 图 10-2) ， 持 续 向 上 的 趋势 一 直 都 
很 稳定 ， 而 且 没 有 停止 的 迹象 。 不 过 ， 抛 开 实 际 的 请 求 和 字 闻 数 不 提 ， 更 值得 关注 
的 还 是 个 别 组 件 的 量 级 : 现在 ,一 个 普通 的 Web 应 用 大 约 就 有 1 MB ， 有 100 个 左 
右 的 资源 分 散在 15 台 不 同 的 主机 上 1 


与 桌面 应 用 相 比 ，Web 应 用 不 需要 单独 安装 ， 只 要 输入 URL， 按 下 回 车 键 ， 就 可 
以 正常 运行 。 可 是 ， 桌 面 应 用 只 需要 安装 一 次 ， 而 Web 应 用 每 次 访问 都 需要 走 一 遍 
“安装 过 程 ” 下 载 资源 、 构 建 DOM 和 CSSOM、 运 行 JavaScript。 正 因为 如 此 ， 
Web 性 能 研究 迅速 发 展 ， 成 为 人 们 热 议 的 话题 也 就 不 足 为 怪 了 。 上 百 个 资源 、 成 兆 
字 节 的 数据 、 数 十 个 不 同 的 主机 ， 所 有 这 些 都 必须 在 短 短 几 百 ms 内 亲密 接触 一 次 ， 
才能 带 来 即刻 呈现 的 Web 体验 。 
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10-2: 平均 规模 和 请 求 数量 (HTTP Archive) 


10.2.1 速度、 性 能 与 用 户 期 望 

速度 和 性 能 是 两 个 相对 的 概念 。 每 个 应 用 都 要 满足 自己 特定 的 需求 ， 因 为 商业 条 件 、 
应 用 场景 、 用 户 期 望 ， 以 及 功能 复杂 性 各 不 相同 。 尽 管 如 此 ， 如 果 应 用 必须 对 用 户 
作出 响应 ， 那 我 们 就 必须 从 用 户 角 度 来 考虑 可 感知 的 处 理 时 间 这 个 和 常量。 事实 上 ， 
虽然 生活 节奏 越 来 越 快 一 一 至 少 我 们 感觉 如 此 ， 但 人 类 的 感知 和 反应 时 间 则 一 直 都 
没有 变 过 ( 表 10-1)， 而且 与 应 用 的 类 型 (在线 或 离线 )、 媒 体 的 类 型 (笔记 本 、 台 
式 机 或 移动 设备 ) 无 关 。 

表 10-1: 时 间 和 用 户 感 觉 

时 间 感觉 

0 ~100 ms 很 快 

100~300 ms 有 一 点 点 慢 

300~1000 ms ”机 器 在 工作 呢 


> 1000 ms 先 干 点 别 的 吧 
> 10000 ms 不 能 用 了 


























5 


这 个 表格 解释 了 Web 性 能 社区 总 结 的 经 验 法 则 :必须 250 ms 内 泻 染 页 面 ， 
心 。 或 者 至 少 提供 视觉 反馈 ， 才 能 保证 用 户 不 走 开 ! 
DSN 
如 果 想 让 人 感觉 很 快 ， 就 必须 在 几 百 ms 内 响应 用 户 操 作 。 超 过 1 s， 用 户 的 预期 流 
程 就 会 中 断 ， 心 思 就 会 向 其 他 任务 转移 ， 而 超过 10 s， 除 非 你 有 反馈 ， 否 则 用 户 基 
本 上 就 会 终止 任务 1 
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现在 ， 把 DNS 查询 ， 随 后 的 TCP 握手 ， 以 及 请 求 网 页 所 需 的 几 次 往返 时 间 都 算 上 ， 
光 网 络 上 的 延迟 就 能 轻易 突破 100~1000 ms 的 预算 (参见 表 8-1)。 难 怪 有 那么 多 用 
户 ， 特 别 是 那些 移动 或 无 线 用 户 ， 抱 她 上 网 速度 慢 了 1! 





FE 
Jakob Nielsen 的 Usability Engineering 和 Steven Seow 的 Desiening and 


心 。 Engineering Time 是 每 一 位 开发 者 和 设计 师 都 应 该 好 好 读 的 书 ! 时 间 测 量 
全 是 客观 的 ， 而 时 间 感 知 是 主观 的 。 我 们 可 以 通过 设计 来 改善 感知 性 能 。 























把 性 能 变 成 钞票 
速度 是 一 种 功能 ， 而 非 简单 的 为 了 速度 而 速度 。 人 谷歌、 微软 和 亚马逊 的 研究 都 表 
明 ， 性 能 可 以 直接 转换 成 收入 。 比 如 ，Bing 搜索 网 页 时 延迟 2000 ms 会 导致 每 用 
户 收入 减少 4.3%。 
类 似 地 ，Aberdeen 一 项 窗 盖 160 多 家 组 织 的 研究 表明 ， 页 面 加 载 时 间 增 加 1 秒 ， 
会 导致 转化 率 损 失 7W%， 页 面 浏 览 量 减少 11%， 客 户 满意 度 降 低 16% | 
网 络 越 快 ，PV 越 多 ， 和 性 越 强 ， 转 化 率 越 高 。 不 过 ， 不 能 只 听 这 些 行 业 调查 的 结 
论 ， 你 还 得 根据 自己 的 标准 来 测量 自己 网 站 的 性 能 。 至 于 为 什么 ， 请 往 下 看 ， 或 
者 直接 跳 到 10.4 节 “ 人 造 和 真实 用 户 性 能 度量 ”。 











10.2.2 ”分析 资源 瀑布 

谈 到 Web 性 能 ， 必 然 要 谈资 源 瀑布 。 事 实 上 ， 资 源 瀑布 很 可 能 是 我 们 可 以 用 来 分 
析 网 络 性 能 ， 诊 断 网 络 问 题 的 一 个 最 有 价值 的 工具 。 很 多 浏览 器 都 内 置 了 一 些 手 
段 ， 让 我 们 能 查看 资源 瀑布 。 此 外 ， 还 有 一 些 不 错 的 在 线 工 具 ， 比 如 WebPageTest 
(http://www.webpagetest.org/) ， 可 以 在 不 同 的 浏览 器 中 呈现 资源 瀑布 。 





5 
， 


WebPageTest.org 是 一 个 开源 免费 的 项 目 ， 可 以 测试 世界 各 地 网 页 的 性 
。 能 。 测 试用 的 浏览 器 在 虚拟 机 中 运行 ， 可 编程 ， 可 配置 ， 有 各 种 连接 和 
浏览 器 设置 可 选 。 测 试 完成 后 ， 通 过 网 页 就 可 以 查看 结果 。 这 一 切 使 得 
WebPageTest 成 为 无 与 伦比 的 Web 性 能 测试 工具 。 






































首先 ， 必 须知 道 每 一 个 HTTP 请 求 都 由 很 多 独立 的 阶段 构成 (图 10-3) : DNS 解 
析 、TCP 连接 握手 、TLS 协商 (必要 时 )、 发 送 HTTP 请 求 ， 然 后 下 载 内 容 。 这 
些 阶段 的 时 长 在 不 同 的 浏览 器 中 会 略 有 不 同 ， 但 为 了 简单 起 见 ， 本 章 就 使 用 
WebPageTest 测试 的 结果 。 请 大 家 提前 熟悉 每 种 颜色 在 自己 浏览 器 中 的 含义 。 
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http:/ Fwww .yahoo .com 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 


DNS Lookup | 国 Initial Connection | ll Time to First Byte | 国 Content Download 


10-3: HTTP 请 求 的 构成 (WebPageTest) 





1. www.yahoo.com - / 











仔细 看 一 下 图 10-3， 打 开 Yahoo! 主页 花 了 683 ms， 而 其 中 有 200 多 ms 在 等 待 网 络 
就 绪 ， 占 到 了 请 求 延 迟 的 30% ! 然而 ， 请 求 文档 还 只 是 开始 ， 现 代 的 Web 应 用 还 
需要 各 种 资源 (图 10-4) 配合 来 生成 最 终结 果 。 准 确 地 说 ， 要 加 载 Yahoo! 主页 ， 浏 
览 器 要 请 求 52 个 资源 ， 从 30 个 不 同 的 主机 获得 ， 这 些 资源 加 起 来 总 共 486 KB 。 

















http:/ /Www .yahoo .com 

1. www.yahoo.com - / 

2. 1.ying.com - combo 
3. ll.yimg.com - pil.gif 
4. 12.yimg.con - pli.gif 
5. 13.yimg.com - pl.gif 
6. l4.yimg.com - pil.gif 
7. 1l.yimg.com - p2.gif 
8. li.yimg.com - p2.gif 
9. l2.yimg.com - p2.gif 
10. 1.yimg.com - pi.gif 
11. 1.ying.com - combo 
12. 1.yimg.com - combo 
13. 1.yimg.com - combo 
14. 13.yimg.com - p2.gif 
15. 14.ying.com - p2.gif 加 106 ns 
16. 1.yimg.con - 120x451ho74qbs3.png 
17. 13.yimg.con - b...250_1363616797 .jpg 
18. 14.yimg.com - b...x48_1363616797 .jpgs 
19. 11.yimg.com - j...x48_1363561086. jpg 
20. l2.yimg.com - M...x48_1363615363.jpg 
21. li1.yimg.com ~ a...x48_1363608320.jpg 
22. 12.yimg.com - 1...x48_1363564400.jpg 






























23. 1.yimg.com - transparent-95031 .png 国 135 MS 
24. 1.ying.com - p.gif 134 ns 
25. 1.ying.com - combo 136 ns 
26. 14.yimg.con - p...rite_0307_10am.png 114 ms 


27. 13.ying.com - video_15x11.png 
28. ads.yimg.com - adchoice_1.png 
29. 1.ying.com - combo 国 148 ns 
30. 1.ying.com - cs_0.2.js 

31. 1.ying.com - bc_2.0.5.js 
32. 1.ying.com - combo 


34. wuw.yahoo.com - ie9_favicon.ico 
35. us.bc.yahoo.com - b 

36. csc.beap.bc.yahoo.com - yi 

37. 1.ying.com - combo 

. b.scorecardresearch.com - p2 

» 1.yimg.com - combo 


» WWW .yahoo .com -...3CO0EdRDDhhO16bvZxd4 


43. 13.yimg .com - 470_2598663.jpg 团 101 ms 
44. 13.yimg .com -~ 1...anne-hough-467 .jpg 国 115 ms 
45. 14.yimg.com - 11h2.gif eo ms 
46. 12.yimg.com - kka.gif N49 ms 
47. 12.yimg.com - gaj.gif 55 ns 


48. 14.ying.com - iie_2.gif 
. d.p-td.com - 52822746 






. ad.yieldmanager .com - imp 
52. 1.ying.com - 300x2501t6t60bm8 .swf 


BanduidthIn (0 - 3,778 Kbps) A en eee een le eee em ee | 


Er rr rr 
10-4: Yahoo.com 资源 瀑布 图 (WebPageTest，2013 年 3 月 ) 
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资源 的 瀑布 图 能 够 揭示 出 页 面 的 结构 和 浏览 器 处 理 顺序 。 首 先 ， 取 得 www.yahoo. 
com 对 应 的 文档 ， 同 时 分 派 新 的 HTTP 请求: HTTP 解析 是 递增 执行 的 ， 这 样 浏 览 
器 可 以 及 早 发 现 必 要 的 资源 ， 然 后 并 行 发 送 请 求 。 实 际 上 ， 何 时 获得 什么 资源 很 大 
程度 上 取决 于 标记 结构 。 浏 览 器 可 以 变更 某 些 请 求 的 优先 顺序 ， 但 递增 地 发 现 文档 
中 的 每 一 个 资源 ， 最 终 造 就 了 不 同 资源 间 的 “瀑布 效果 ”。 


其 次 ,“Start Render”( 绿 色 的 竖 线 ) 会 在 所 有 资源 下 载 完 成 前 开始 ， 以 便 用 户 在 页 
面 构建 期 间 就 能 与 之 交互 。 其 实 , “Document Complete” 事 件 〈 蓝 色 的 坚 线 ) 也 会 
在 剩余 资源 下 载 完成 前 触发 。 换 名 话说， 浏览 器 的 加 载 旋转 图 标 此 时 停止 旋转 ， 用 
户 可 以 继续 与 页 面 交 互 ， 但 Yahoo! 主页 会 渐进 地 在 后 台 填 充 后 续 内 容 ， 比 如 广告 
和 社交 部 件 。 


最 早 泻 染 时 间 、 文 档 完成 时 间 和 最 后 资源 获取 时 间 ， 这 三 个 时 间 说 明 我 们 讨论 Web 
性 能 时 有 三 个 不 同 测 量 指标 。 我 们 应 该 关注 哪 一 个 时 间 呢 ? 答案 并 不 唯一 ， 因 应 用 
而 不 同 ! Yahool 的 工程 师 们 选择 了 利用 浏览 器 递增 加 载 机 制 ， 让 用 户 能 够 尽早 与 
重要 内 容 交 互 。 而 这 样 一 来 ， 他 们 必须 根据 应 用 不 同 ， 确 定 哪 些 内 容重 要 ( 须 先 加 
载 ) ， 哪 些 内 容 不 重要 〈 可 以 后 填充 ) 。 


























Ed 人 
什么 时 候 请 求 什么 资源 ， 以 什么 顺序 请 求 资源 ， 这 在 不 同 的 浏览 器 中 可 能 
人 4 、 有 不 同 的 实现 。 结 果 ， 你 的 应 用 性 能 也 会 因 浏览 器 而 异 。 
心 ' 提示 : WebPageTest 支持 选择 位 置 和 浏览 器 。 





网 络 的 瀑布 图 是 个 很 强大 的 工具 ， 有 助 于 揭示 任何 页 面 或 应 用 是 否 处 于 优化 状态 。 
前 面 分 析 和 优化 资源 课 布 的 过 程 ， 一 般 称 为 前 冯 性 能 分 析 和 优化 。 不 过 ， 这 个 称呼 
有 误导 性 ， 好 像 所 有 性 能 瓶颈 都 在 客户 端 似 的 。 实 际 上 ， 尽 管 JavaScript、CSS 和 
泻 染 流水 线 很 重要 ， 而 且 资 源 对 性 能 影响 很 大 ， 但 服务 器 响应 时 间 和 网 络 延迟 (“后 
端 性 能 ”) 对 资源 瀑布 的 影响 也 不 容 忽 视 。 毕 竞 ， 如 果 网 络 被 阻塞 ， 也 就 谈 不 上 什么 
解析 或 运行 资源 了 1 


为 了 说 明 这 一 点 ， 只 要 切换 到 WebPageTest 资源 瀑布 的 连接 视图 即 可 (图 10-5)。 





资源 瀑布 图 记录 的 是 HTTP 请 求 ， 而 连接 视图 展示 了 每 个 TCP 连接 (这 里 共 30 
个 ) 的 生命 期 这些 连接 用 于 获取 Yahoo! 主页 的 资源 。 哪 里 比较 突出 呢 ?” 注 意 蓝 
色 的 下 载 时 间 ， 很 得， 在 每 个 连接 的 总 延迟 里 几乎 微不足道 。 这 里 总 共 发 生 了 15 
次 DNS 查询 ，30 次 TCP 握手 ， 还 有 很 多 等 待 接 收 每 个 响应 第 一 个 字 节 的 网 络 延迟 
(绿色 ) 。 
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http:/ /www .yahoo .com 
1. www.yahoo .com 
2. Www .yahoo .com 
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4. 1.yimg.com 
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6. 1.yimg.com 
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Ed 人 
四 为 什么 有 些 请 求 只 显示 绿色 条 (第 一 字 节 接收 时 间 ) ? 因为 很 多 响应 很 小 ， 
心 。 相 应 的 下 载 时 间 设 有 在 图 中 体现 。 事 实 上 ， 请 求 、 响 应 的 主要 时 间 通 常 是 
心 ， 往返 延迟 和 服务 器 处 理 时 间 。 














最 后 ， 也 是 最 重要 的 ， 连 接 视 图 的 底部 显示 了 带宽 利用 率 曲线 。 除 了 少量 数据 爆发 
外 ， 可 用 连接 的 带宽 利用 率 很 低 。 这 说 明 性 能 的 限制 并 不 在 带宽 ! 难道 这 是 个 异常 
现象 ， 或 者 浏览 器 问题 ? 都 不 是 。 对 大 多 数 应 用 而 言 ， 带 宽 的 的 确 确 不 是 性 能 的 限 
制 因素 。 限 制 Web 性 能 的 主要 因素 是 客户 端 与 服务 器 之 间 的 网 络 往返 延迟 。 


E33 2 SS 二 N= \ 下 
10.3 ”性 能 来 源 : 计算 、 泻 染 和 网 络 访问 
Web 应 用 的 执行 主要 涉及 三 个 任务 : 取得 资源 、 页 面 布局 和 演 染 、JavaScript 执行 。 
其 中 ， 泻 染 和 脚本 执行 在 一 个 线程 上 交错 进行 ， 不 可 能 并 发 修改 生成 的 DOM。 实 
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际 上 ， 优 化 运行 时 的 泻 染 和 脚本 执行 是 至 关 重 要 的 ， 可 以 参考 10.1 节 中 的 “DOM、 
CSSOM 和 JavaScript”。 


可 是 ， 就 算 优 化 了 JavaScript 执行 和 泻 染 管道 ， 如 果 浏 览 器 因 网 络 阻 塞 而 等 待 资源 
到 来 ， 那 结果 也 好 不 到 哪里 去 。 对 运行 在 浏览 器 中 的 应 用 来 说 ， 迅 速 而 有 效 地 获取 
网 络 资源 是 第 一 要 义 。 


有 人 可 能 会 问 ， 互 联网 今天 的 速度 不 是 快 多 了 吗 ， 难 道 网 络 还 会 阻塞 ? 是 的 ， 我 们 
的 应 用 也 比 以 前 大 多 了 。 然 而 ， 假 如 真 像 每 个 ISP 和 移动 运营 商 鼓吹 的 那样 ， 全 球 
平均 网 速 已 经 达到 3.1 Mbit/s (参见 1.6 市 “网 络 边缘 的 带宽 ”)， 而 且 还 在 继续 提 
速 ，Web 应 用 大 一 点 又 算得 了 什么 呢 ? 可 惜 的 是 ， 赁 直觉 以 及 前 面 展 示 的 Yahool 
的 合子， 我 们 知道 如 果真 是 这 样 ， 那 你 就 不 用 再 看 这 本 书 了 。 好 ， 下 面 我 们 仔细 谈 


一 谈 。 

















要 想 详细 了 解 带 宽 和 延迟 的 发 展 趋势 及 其 相互 影响 ， 请 参考 第 1 章 “ 延 迟 
4 4 、 与 带宽 ” 
[mn 





10.3.1 更 多 带宽 其 实 不 (大 ) 重要 

先 别 急 ， 带 宽 当 然 重要 ! 毕 况 ,所 有 ISP 和 移动 运营 商 的 广告 ， 都 意 在 提醒 我 们 高 
带宽 的 好 处 ， 上 传 和 下 载 加 速 、 更 流畅 地 欣赏 视频 ， 都 有 赖 于 [ 请 读者 在 此 插入 最 
新 数字 ] Mbit/s 的 速度 ! 


能 接 入 更 高 带宽 固然 好 ， 特 别 是 传输 大 块 数据 时 更 是 如 此 ， 比 如 在 线 听 音 乐 、 看 视 
频 ， 或 者 下 载 大 文件 。 可 是 ,日 常 上 网 浏览 需要 的 是 从 数 十 台 主 机 获取 较 小 的 资源 ， 
这 时 候 往返 时 间 就 成 了 瓶颈 : 

。 在 Yahoo! 主页 上 看 视频 受 限 于 带宽 ， 

。 加 载 和 浑 染 Yahoo! 主页 受 限于 延迟 。 





根据 在 线 视频 品质 及 编码 不 同 ， 需 要 的 带宽 从 几 百 Kbit/s 到 几 Mbit/s 不 等 。 比 如 ， 
要 流畅 观看 1080P 的 高 清 视频 ， 需 要 3 Mbit/s 以 上 的 带宽 。 这 个 带宽 是 很 多 用 户 触 
手 可 及 的 ，Netflix 等 在 线 视 频 网 站 的 流行 也 印证 了 这 一 点 。 那 么 ， 为 什么 下 载 比 视 
频 小 得 多 得 多 Web 应 用 ， 在 能 流畅 观看 高 清 视频 的 连接 上 却 成 了 难题 呢 ? 





10.3.2 ”延迟 是 性 能 瓶颈 
关于 为 什么 延迟 会 成 为 浏览 网 页 的 限制 因素 ， 前 几 章 已 经 介绍 了 足够 多 的 理论 知识 ， 
只 是 那些 都 只 能 给 我 们 一 个 定性 的 认识 。 下 面 ， 我 们 就 来 通过 两 张 图 (图 10-6) ， 定 
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量 地 感受 一 下 不 同 的 带宽 和 延迟 时 间 对 页 面 加 载 时 间 分 别 有 什 么 影响 。 这 两 张 
图 来 自 SPDY 协议 的 开发 者 之 一 Mike Belshe， 测 试 的 是 互联 网 上 最 热门 的 一 些 
站 点 。 








1Mbps 2Mbps 3Mbps 4Mbps SMbps 6Mbps 7Mbps 8Mbps 9Mbps 10Mbps 


延迟 减少 





200ms 180ms 160ms 140ms 120ms 100 ms 80 ms 60ms 40 ms 20 ms 











图 10-6: 页 面 加 载 时间 与 带宽 和 延迟 的 关系 
a 

, Mike Belshe 的 研究 是 谷歌 开发 SPDY 协议 的 依据 ， 而 SPDY 就 是 后 来 
CA 


ww 4 ，HTTP 2.0 的 基础 。 
“4 





在 第 一 个 测试 中 ， 连 接 的 延迟 时 间 固 定 而 带宽 递增 ， 从 1 Mbit/s 依次 递增 至 10 
Mbit/s。 注 意 一 开始 ， 从 1 Mbit/s 升级 到 2 Mbit/s， 页 面 加 载 时 间 几 平 减少 了 一 半 ， 
这 也 是 我 们 希望 看 到 的 结果 。 可 是 ， 在 此 之 后 ， 带 宽 递 增 ， 加 载 时 间 减 少 得 越 来 
越 不 明显 。 而 当 带 宽 超过 5 Mbits 时 ， 加 载 时间 的 减少 比例 只 有 几 个 百分点 ， 从 5 
Mbit/s 升级 到 10 Mbitys， 页 面 加 载 时 间 仅 降低 了 59% ! 





Akamai 公司 的 宽带 速度 报告 (参见 1.6 节 “ 网 络 边缘 的 带宽 ") 显示 ， 美 国 普通 消 
费 者 上 网 带宽 已 经 达到 5 Mbit/s 以 上 。 很 多 其 他 国家 很 快 也 能 达到 这 个 数字 ， 甚 至 
有 的 已 经 超过 了 它 。 由 此 可 知 ， 靠 提高 带宽 不 会 给 美国 人 浏 览 网 页 带 来 多 大 的 性 能 
提升 。 或 许 美 国人 下 载 大 文件 、 看 视频 的 速度 很 快 ， 但 加 载 包 含 这 些 文件 的 页 面 的 
时 间 不 会 明显 缩短 。 换 句 话 说， 增加 带宽 没有 那么 重要 。 


然而 ， 在 延迟 以 20 ms 递减 的 试验 中 ， 页 面 加载 时 间 呈 线性 减少 趋势 。 在 选择 ISP 
时 ， 是 不 是 应 该 把 延迟 时 间 而 不 是 带宽 放 在 首位 呢 ? 
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要 让 互联 网 从 整体 上 提速 ， 就 必须 寻求 降低 RTT 的 方法 。 把 跨 大 西洋 的 
RTT 从 150 ms 降低 到 100 ms， 结 果 会 怎么 样 ? 结果 比 把 用 户 带 宽 从 3.9 
Mbit/s 提高 到 10 Mbit/s 甚至 1 Gbit/s 对 速度 的 影响 都 大 。 

减少 页 面 加 载 时 间 的 另 一 种 方法 , 就 是 减少 加 载 每 个 页 面 过 程 中 的 往返 次 数 。 
今天 ， 加 载 每 个 页 面 者 需要 客户 端 到 服务 器 之 间 的 数 次 往返 。 这 些 往 返 很 大 
程度 上 是 由 客户 端 与 服务 器 之 间 为 建立 连接 (DNS、TCP、HTTP 等 ) 而 进 
行 握手 所 导致 的 ， 当 然 有 的 是 由 通信 协议 引发 的 (如 TCP 慢 启 动 )。 假 如 我 

们 能 够 对 协议 加 以 改进 ， 使 得 加 载 同样 多 的 数据 只 需 更 少 的 往返 ， 那 应 该 也 

能 够 减少 页 面 加 载 时 间 。 这 就 是 SPDY 的 目标 之 一 。 

Mike Belshe， 更 多 带宽 其 实 不 ( 太 ) 重要 
很 多 人 可 能 都 会 惊讶 于 这 两 项 试验 的 结果 ， 而 实际 情况 的 确 如 此 ， 这 正 是 TCP 握手 
机 制 、 流 量 和 拥塞 控制 、 由 丢 包 导致 的 队 首 拥塞 等 底层 协议 特点 影响 性 能 的 直接 后 
果 。 大 多 数 HTTP 数据 流 都 是 小 型 突 发 性 数据 流 ， 而 TCP 则 是 为 持久 连接 和 大 块 数 
据 传输 而 进行 过 优化 的 。 网 络 往返 时 间 在 大 多 数 情况 下 都 是 TCP 吞吐 量 和 性 能 的 限 
制 因素 ， 详 细 信 息 可 参见 2.5 节 “ 针 对 TCP 的 优化 建议 ”。 于 是 ， 延 迟 自然 也 就 成 
了 HTTP 及 大 多 数 基于 HTTP 交付 的 应 用 的 性 能 瓶颈 。 


二 六 








如 果 延 迟 对 大 多 数 有 线 连接 是 限制 性 能 的 因素 ， 那 可 想 而 知 ， 它 对 无 线 客 
心 4， 户 端 将 是 更 重要 的 性 能 瓶颈 。 事 实 上 ， 无 线 延迟 明显 更 高 ， 因 此 网 络 优化 
心 ， 是 提升 移动 Web 应 用 性 能 的 关键 。 


10.4 ”人造 和 真实 用 户 性 能 度量 


有 度量 ， 才 有 改进 。 问 题 在 于 度量 的 标准 是 否 正确 ， 过 程 是 否 合理 。 如 前 所 述 ， 度 
量 现 代 Web 应 用 的 性 能 并 不 容易 ， 没 有 什么 指标 放 之 四 海 错 准 。 换 句 话说， 我 们 必 
须 定 义 自己 的 指标 。 确 定 了 度量 标准 之 后 ， 接 下 来 要 收集 性 能 数据 ， 这 个 过 程 涉及 
一 系列 人 造 和 真实 用 户 的 性 能 度量 。 


宽泛 地 说 ， 在 受 控 度量 环境 下 完成 的 任何 测试 都 可 称 为 人 造 测 试 。 首 先 ， 本 地 构建 
过 程 运 行 性 能 套件 ， 针 对 基础 设施 加 载 测 试 ， 或 者 针对 一 组 分 散在 各 地 的 监控 服务 
器 加 载 测 试 ， 这 些 服务 器 定时 运行 脚本 并 记录 输出 。 这 些 测试 中 的 任何 一 个 都 可 能 
测试 不 同 的 基础 设施 (如 应 用 服务 器 的 否 吐 量 、 数 据 库 性 能 、DNS 时 间 ， 等 等 )， 
并 作为 稳定 的 基准 辅助 检测 性 能 衰退 或 聚焦 于 系统 的 某 个 特定 组 件 。 



























































册 


¥ a 
‘i 只 要 配置 得 当 ， 人 造 测试 就 可 以 提供 一 个 受 控 且 可 重 现 的 性 能 测试 环境 。 
人 
4 





。 而 这 个 环境 非常 适合 发 现 和 修复 性 能 问题 ， 确 保 用 户 体验 。 提 示 : 确定 一 


”个 关键 的 性 能 指标 ， 并 为 它们 分 别 设 定 一 个 “预算 额度 " ， 纳 入 人 造 测试 计 
划 。 一旦 哪 个 指标 超出 “预算 ”， 马 上 拉 响 警报 ! 
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可 是 ， 人 造 测 试 不 能 发 现 所 有 性 能 瓶颈。 特别 是 在 人 造 环境 下 收集 到 的 性 能 数据 
缺乏 现实 当中 的 多 样 性 ， 难 以 据 之 确定 应 用 带 给 用 户 的 最 终 体 验 。 这 个 问题 有 如 下 

















表现 。 


。 场景 及 页 面 选择 : 很 难 重复 真实 用 户 的 导航 模式 ， 
。 浏览 器 缓存 : 用 户 缓存 不 同 ， 性 能 差别 很 大 ， 

。 中 介 设 施 : 中间 代 理 和 缓存 对 性 能 影响 很 大 ， 

。 硬件 多 样 化 :不同 的 CPU、GPU 和 内 存 比比 皆 是 ， 
。 浏览 器 多 样 化 : 各 种 浏览 器 版 本 ， 有 新 有 旧 ， 

。 上 网 方式 : 真实 连接 的 带宽 和 延迟 可 能 不 断 变化 。 














上 述 这 些 方面 ， 加 之 其 他 一 些 类 似 情况 ， 意 味 着 除了 人 造 测试 ， 我 们 必须 通过 真实 
用 户 度量 (RUM，Real-User Measurement) 来 获取 用 户 使 用 我 们 应 用 的 真实 性 能 3 

据 ， 从 而 确保 性 能 度量 的 有 效 性 。 有 一 个 好 消息 ，W3C Web Performance Working 
Group 通过 引入 Navigation Timing API (图 10-7) 为 我 们 做 真实 用 户 测 试 提供 了 便 

















利 ， 这 个 API 目前 已 得 到 很 多 现代 桌面 和 移动 浏览 器 的 支持 。 












navigationStart 
redirectStart 
redirectEnd 
fetchStart 
domainLookupStart 
domainLookupEnd 
connectStart 
(secureConnectionStart) loadEventEnd 
et loadEventStart 
/ [a responseStart | 


提示 应 用 1 

、|| 重 定向 DNS||rcP|| ”请 求 

缓存 

DOMContentLoaded 

本 domComplete 
domContentLoadedEventEnd 
domContentLoadedEventStart 
domlnteractive 
domLoading 


unloadEventEnd 
unloadEventStart 



























10-7: Navigation Timing 监测 到 的 特定 于 用 户 的 计时 器 


地 
Ga 2014 年 初 ， 支 持 Navigation Timing 的 浏览 器 有 IE9+、Chrome 6+、Firefox 7+ 
4 4， 和 opera 15+， 包 括 桌 面 和 移动 版 本 ，Safari 还 不 支持 。 要 了 解 最 新 情况 ， 
0 


“人 ”请 参考 http://caniuse.com/nav-timing。 








Web 性 能 要 点 | 


155 


Navigation Timing 的 真正 好 处 是 它 提 供 了 以 前 无 法 访问 的 数据 ， 比 如 DNS 和 TCP 
连接 时 间 ， 而 且 精 确 度 极 高 ( 微 秒 级 时 间 惟 )。 要 获得 这 些 数 据 ， 可 以 在 浏览 器 中 访 
问 标 准 的 performance. timing 对 象 。 实际 上 ， 收 集 这 些 数据 的 过 程 很 简单 : 加 载 页 
面 ， 从 用 户 浏 览 器 中 取得 相应 的 计时 对 象 ， 然 后 将 其 传 回 分 析 服 务 器 ! 通过 观察 这 
些 数 据 ， 就 可 以 知道 用 户 使 用 我 们 应 用 时 的 真实 性 能 ， 发 现 不 同 硬件 和 不 同 网 络 连 
接 导致 的 差异 。 








分 析 真 实用 户 度量 数据 
分 析 性 能 数据 时 ， 要 时 时 关注 数据 的 潜在 分 布 ， 抛 开 均 值 ， 多 用 直方 图 、 中 位 值 
和 分 位 数 。 对 于 偏 态 分 布 和 多 重 模 态 分 布 ， 均 值 是 个 没有 意义 的 指标 。 图 10-8 展 
示 了 同一 站 点 度量 数据 的 这 两 种 分 布 ， 其 中 偏 态 分 布 显 示 的 是 页 面 加 载 时 间 ， 而 
多 重 模 态 分 布 显示 的 是 服务 器 响应 时 间 (两 种 模式 分 别 是 应 用 服务 器 生成 有 缓存 
和 无 缓存 页 面 的 时 间 )。 


间 段 ( 秒 ) 载 采样 

EEE CE ET 
EE CE 
EE CE ET 
wo OE 


时 间 段 ( 秒 ) 

ETT TO 
[TI 一 
| 


图 10-8: igvita.com 的 页 面 加载 时 间 ( 偏 态 ) 和 响应 时 间 (多 重 模 态 ) 分 布 


要 确保 自己 的 分 析 工 具 能 够 针对 性 能 数据 得 到 正确 的 统计 结果 。 前 面 的 数据 来 
自 Google Analytics， 它 和 本 准 的 “站 点 速度 ”报告 中 提供 了 查访 图 。Google 
Analytics 会 在 安装 分 析 跟 踪 器 的 情况 下 自动 收集 Navigation Timing 数据 。 类 似 地 ， 
还 有 很 多 第 三 方 开发 商 提供 了 基于 Navigation Timing 的 数据 收集 和 报告 工具 。 
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最 后 ， 除 了 Navigation Timing，W3C Performance Group 还 标准 化 了 另外 两 个 API: 
User Timing 和 Resource Timing。Navigation Timing 只 针对 根 文档 提供 性 能 计时 器 ， 
Resource Timing 则 针对 页 面 中 的 每 个 资源 都 提供 类 似 的 性 能 数据 ， 可 以 让 我 们 收集 
到 关于 页 面 的 完整 性 能 数据 。 类 似 地 ，User Timing 也 是 一 个 简单 的 JavaScript APT1， 
可 以 标记 和 度量 特定 应 用 的 性 能 指标 ， 提 供 高 精确 度 的 计时 结果 : 
function init() { 
performance.mark("startTask1"); © 


applicationCode1(); 外 
performance.mark("endTask1"); 


logPerformance(); 


} 


function logPerformance() { 
var perfEntries = performance.getEntriesByType("mark"); 
for (var i = 0; i < perfEntries.Length; i++) { 


console.log("Name: " + perfEntries[i].name + 
" Entry Type: " + perfEntries[i].entryType + 
" Start Time: " + perfEntries[i].startTime + 
" Duration: " + perfEntries[i].duration + "\n"); 


console.log(performance.timing); @ 


} 
@ 存储 (标记 ) 时 间 惟 ， 并 命名 (startTask1) 
@ ”执行 应 用 代码 
加 ” 友 代 和 记录 用 户 计时 数据 
@ 记录 当前 页 面 的 Navigation Timing 对 象 


综合 运用 Navigation、Resource 和 User 计时 API， 可 以 对 每 个 Web 应 用 的 真实 用 
户 性 能 进行 度量 ， 再 也 不 要 说 没有 精确 的 数据 了 ! 优化 要 以 度量 为 依据 ，RUM 和 人 
造 测试 是 互 为 补充 的 手段 ， 可 以 帮 有 我 们 发 现 回归 现象 和 真正 的 瓶颈 ， 提 升 应 用 的 用 
户 体验 。 





可 靠 的 性 能 优化 策略 源 自 特定 于 应 用 的 自 定义 指标 。 不 存在 唯一 度量 和 定 

。 义 用 户 体验 的 方式 。 相 反 ， 我 们 必须 针对 每 个 应 用 定义 和 设计 特定 的 里 程 

尾 ， 碑 和 活动 ， 这 是 一 个 涉及 所 有 干系 人 (公司 老总 、 设 计 师 和 开发 人 员 ) 的 
协作 过 程 。 


| UA 、 + 
10.5 ”针对 浏览 器 的 优化 建议 
不 得 不 说 ， 浏 览 器 可 远 远 不 止 一 个 网 络 套 接 字 管 理 器 那么 简单 。 性 能 可 以 说 是 每 个 
浏览 器 开发 商 的 核心 卖点 ， 既 然 性 能 如 此 重要 ， 那 浏 览 器 越 来 越 聪 明 也 就 毫 不 奇怪 


A 
(0 


, 
半 
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了 。 
些 


预 解析 可 能 的 DNS 查询 、 预 连接 可 能 的 目标 、 预 取得 和 优先 取得 重要 资产 ， 这 


都 是 浏览 器 变 聪明 的 标志 。 


可 行 的 优化 手段 会 因 浏 览 器 而 异 ， 但 从 核心 优化 策略 来 说 ， 可 以 宽泛 地 分 为 两 类 。 





基于 文档 的 优化 

熟悉 网 络 协议 ， 了 解 文档 、CSS 和 JavaScript 解析 管道 ， 发 现 和 优先 安排 关键 网 
络 资源 ， 尽 早 分 派 请 求 并 取得 页 面 ， 使 其 尽快 达到 可 交互 的 状态 。 主 要 方法 是 优 
先 获 取 资 源 、 提 前 解析 等 。 

推测 性 优化 

浏览 器 可 以 学 习 用 户 的 导航 模式 ， 执 行 推测 性 优化 ， 尝 试 预测 用 户 的 下 一 次 操 
作 。 然 后 ， 预 先 解析 DNS、 预 先 连接 可 能 的 目标 。 





好 消息 是 ， 所 有 这 些 优 化 都 由 浏览 器 替 我 们 自动 完成 ， 经 常 可 以 节省 几 百 ms 的 网 
络 延迟 。 既 然 如 此 ， 那 理解 这 些 优化 背后 的 原理 就 至 关 重 要 了 ， 这 样 才 能 利用 浏览 
器 的 这 些 特性 ， 提 升 应 用 性 能 。 大 多 数 浏 览 器 都 利用 了 如 下 四 种 技术 。 





资源 预 取 和 排 定 优先 次 序 

文档 、CSS 和 JavaScript 解析 器 可 以 与 网 络 协议 层 沟 通 ， 声 明 每 种 资源 的 优先 
级 : 初始 谊 染 必 需 的 阻塞 资源 具有 最 高 优先 级 ， 而 低 优先 级 的 请 求 可 能 会 被 临时 
保存 在 队列 中 。 


DNS 预 解析 
对 可 能 的 域名 进行 提前 解析 ， 避 免 将 来 HTTP 请 求 时 的 DNS 延迟 。 预 解析 可 以 
通过 学 习 导 航 历 史 、 用 户 的 鼠标 悬 停 ， 或 其 他 页 面 信号 来 触发 。 


TCP 预 连接 
DNS 解析 之 后 ， 浏 览 器 可 以 根据 预测 的 HTTP 请 求 ， 推 测 性 地 打开 TCP 连接 。 
如 果 猜 对 的 话 ， 则 可 以 节省 一 次 完整 的 往返 〈TCP 握手 ) 时 间 。 


页 面 预 演 米 
某 些 浏览 器 可 以 让 我 们 提示 下 一 个 可 能 的 目标 ， 从 而 在 隐 蕊 的 标签 页 中 预先 演 染 
整个 页 面 。 这 样 ， 当 用 户 真 的 触发 导航 时 ， 就 能 立即 切换 过 来 。 


增 所 











要 了 解 谷歌 Chrome 浏览 器 是 如 何 实现 这 些 及 其 他 网 络 优化 机 制 的 ， 请 参考 


4 “High Performance Networking in Google Chrome” | 6 
yh 





从 外 部 看 ， 现 代 浏 览 器 的 网 络 协议 实现 以 简单 的 资源 获取 机 制 的 面目 示人 ， 而 从 内 
部 来 说 ， 它 又 极为 复杂 精密 ， 为 了 解 如 何 优化 性 能 ， 非 常 值得 深入 钻研 。 那 么 ， 在 
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探寻 的 过 程 中 ， 我 们 怎么 利用 浏览 器 的 这 些 机 制 呢 ? 首先 ， 要 密切 关注 每 个 页 面 的 
结构 和 交付 : 


。 CSS 和 JavaScript 等 重要 资源 应 该 尽早 在 文档 中 出 现 ; 

。 应 该 尽早 交付 CSS， 从 而 解除 浑 染 阻塞 并 让 JavaScript 执行 ，; 

。 非 关 键 性 JavaScript 应 该 推迟 ， 以 避免 阻塞 DOM 和 CSSOM 构建 ; 

。 HTML 文档 由 解析 器 递增 解析 ， 从 而 保证 文档 可 以 间隙 性 发 送 ， 以 求 得 最 佳 性 能 
除了 优化 页 面 结构 ， 还 可 以 在 文档 中 租 入 提示 ， 以 触发 浏览 器 为 我 们 采用 其 他 优化 
机 人 制 | : 











<Link rel="dns-prefetch" href="//hostname_to_resoLve.com"> © 
<Link reL="subresource" href="/javascript/myapp.js"> @ 


<link rel="prefetch" href=" /images/big.jpeg"> © 
<link rel="prerender" href="//exampLe.org/next_page.htmL"> @ 
@ 预 解析 特定 的 域名 


@ 预 取 得 页 面 后 面 要 用 到 的 关键 性 资源 

@ 预 取得 将 来 导航 要 用 的 资源 

@ 根据 对 用 户 下 一 个 目标 的 预测 ， 预 演 染 特定 页 面 

这 里 的 每 一 个 提示 都 会 触发 一 个 推测 性 优化 机 制 。 浏 览 器 虽然 不 能 保证 落实 ， 但 可 
以 利用 这 些 提示 优化 加 载 策 略 。 可 惜 的 是 ， 并 非 所 有 浏览 器 都 支持 这 些 提示 ( 表 


10-2)。 不 过 ， 如 果 它 们 不 支持 ， 也 只 会 把 提示 当成 空 操作 ， 有 益 无 害 。 因 此 ， 一 
要 尽 可 能 利用 这 些 手 段 。 


表 10-2: 推测 性 浏览 器 优化 提示 








浏览 器 DNS 预 获取 重要 资源 预 获取 预 泻 染 
Firefox 3.5+ N/A 3.5+ N/A 
Chrome 1.0+ 1.0+ 1.0+ 13+ 
Safari 5.01+ N/A N/A N/A 
EE 9+ ( 预 获取 ) N/A 10+ 11+ 


IE9 支持 “DNS 预 获 取 ”， 但 叫 “ 预 获取 ” (prefetch ) 。 在 正 10+ 中 ， dns-prefetch 
人 慌 4 ， 和 prefetch 是 等 价 的 ， 都 能 用 于 指定 DNS 预 获取 。 


, 
(0, 





对 大 多 数 用 户 甚至 Web 开发 者 而 言 ， DNS、TCP 和 SSL 延迟 完全 不 可 见 ， 它 们 都 是 
在 网 络 层 协商 确定 的 ， 我 们 中 很 少 有 人 关注 它们 。 然 而 ， 这 其 中 每 一 步 都 关乎 整体 的 
用 户 体验 ， 因 为 每 一 次 额外 的 网 络 往返 都 会 增加 几 十 甚至 几 百 ms 的 网 络 延 迟 。 通 过 
帮助 浏览 器 预测 这 些 往返 ， 可 以 消 除 这 些 瓶 颈 ， 从 而 向 用 户 交 付 更 快 更 好 的 体验 。 
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谷歌 搜索 对 TTFB (Time To First Byte) 的 优化 


HTML 文档 在 浏览 器 中 是 递增 解析 的 。 什 么 意思 呢 ? 就 是 服务 器 会 尽 可 能 频繁 发 
送 文档 的 每 一 可 用 部 分 。 这 样 客户 端 才能 尽早 发 现 和 获取 关键 资源 。 


谷歌 搜索 是 利用 这 一 技术 的 最 佳 范例 。 接 到 搜索 请 求 后 ， 服 务 器 立即 向 浏览 器 发 
送 搜索 页 面 的 静态 头 部 (或 页 局 ) ， 此 时 甚至 尚未 分 析 查 询 。 也 是 啊 ， 为 什么 要 
耽搁 呢 ， 每 个 搜索 页 面 的 头 部 都 是 一 样 的 ! 然后 ， 在 客户 端 解析 头 部 的 同时 ， 服 
务 器 开始 搜索 索引 ， 在 结果 准备 好 之 后 ， 再 将 包含 搜索 结果 的 文档 剩余 部 分 发 送 
给 客户 端 。 此 时 ， 再 通过 JavaScript 将 头 部 的 动态 内 容 (比如 登录 用 户 的 名 字 ) 
写 进 去 。 
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第 11 章 
HTTP 1.x 





HTTP 1.0 的 优化 策略 非常 简单 ， 就 一 句 话 : 升级 到 HTTP 1.1。 完 了 ! 


改进 HTTP 的 性 能 是 HTTP 1.1 工作 组 的 一 个 重要 目标 ， 后 来 这 个 版 本 也 引入 了 大 
量 增强 性 能 的 重要 特性 ， 其 中 一 些 大 家 比较 熟知 的 有 : 


。 持久 化 连接 以 支持 连接 重用 ， 

。 分 块 传输 编码 以 支持 流 式 响应 ， 

。 请 求 管道 以 支持 并 行 请 求 处 理 ， 

。 字 市 服务 以 支持 基于 范围 的 资源 请 求 ， 
。 改进 的 更 好 的 缓存 机 制 。 


当然 ， 这 些 只 是 其 中 一 ， 要 全 面 讨论 HTTP 1.1 的 所 有 增强 特性 ， 非 得 用 一 本 
书 不 可 。 同 样 ， 3 本 《HTTP 权威 指南 》 (David Gourley 和 Brian Totty 
合 著 ) 放 在 手边 。 另 外 ， 提 到 好 的 参考 书 ，Steve Souder 的 《高 性 能 网 站 建设 指南 》 
中 概括 了 14 条 规则 ， 有 一 半 针 对 网 络 优化 : 











。 碱 少 DNS 查询 
每 次 域名 解析 都 需要 一 次 网 络 往返 ， 增 加 请 求 的 延迟 ， 在 查询 期 间 会 阻塞 请 求 。 


。 减少 HTTP 请 求 
任何 请 求 都 不 如 没有 请 求 更 快 ， 因 此 要 去 掉 页 面 上 没有 必要 的 资源 。 
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。 使 用 CDN 
从 地 理 上 把 数据 放 到 接近 客户 端的 地 方 ， 可 以 显著 减少 每 次 TCP 连接 的 网 络 延 
迟 ， 增 加 吞吐 量 。 


。 添加 Expires 首 部 并 配置 ETag 标 签 
相关 资源 应 该 缓存 ， 以 避免 重复 请 求 每 个 页 面 中 相同 的 资源 。Expires 首部 可 用 
于 指定 缓存 时 间 ， 在 这 个 时 间 内 可 以 直接 从 缓存 取得 资源 ， 完 全 避免 HTTP 请 
求 。ETag 及 Last-Modified 首部 提供 了 一 个 与 缓存 相关 的 机 制 ， 相 当 于 最 后 一 次 
更 新 的 指纹 或 时 间 戳 。 








。 Gzip 资源 
所 有 文本 资源 都 应 该 使 用 Gzip 压缩 ， 然 后 再 在 客户 端 与 服务 器 间 传 输 。 一 般 来 
说 ，Gzip 可 以 减少 60%~80% 的 文件 大 小 ， 也 是 一 个 相对 简单 (只 要 在 服务 器 上 
配置 一 个 选项 ) ， 但 优化 效果 较 好 的 举措 。 





。 避免 HTTP 重 定向 
HTTP 重 定向 极其 耗 时 ， 特别 是 把 客户 端 定向 到 一 个 完全 不 同 的 域名 的 情况 下 ， 
还 会 导致 额外 的 DNS 查询 、TCP 连接 延迟 ， 等 等 。 


上 面 每 一 条 建议 都 经 受 了 时 间 检 验 ， 无 论 是 该 书 出 版 的 2007 年 还 是 今天 ， 都 是 适 
用 的 。 这 并 不 是 巧合 ， 而 是 因为 所 有 这 些 建议 都 反映 了 两 个 根本 方面 :消除 和 减少 
不 必要 的 网 络 延迟 ， 把 传输 的 字 市 数 降 到 最 少 。 这 两 个 根本 问题 永远 是 优化 的 核心 ， 
对 任何 应 用 都 有 效 。 


可 是 ， 对 所 有 HTTP 1.1 的 特性 和 最 佳 实践 ， 我 们 就 不 能 这 么 说 了 。 因 为 有 些 HTTP 
1.1 特性 ， 比 如 请 求 管 道 ， 由 于 缺乏 支持 而 流产 ， 而 其 他 协议 限制 ， 比 如 队 首 响应 阻 
塞 ， 则 导致 了 更 多 问题 。 为 此 ，Web 开发 社区 (一 直 都 最 有 创造 性 )， 创 造 和 推行 
了 很 多 自 造 的 优化 手段 : 域名 分 区 、 连 接 文件 、 拼 合 图 标 、 秽 入 代码 ， 等 等 ， 不 下 
数 十 种 。 


对 多 数 Web 开发 者 而 言 ， 所 有 这 些 都 是 切实 可 行 的 优化 手段 : 熟悉 、 必 要 ， 而 且 

通用 。 可 是 ， 现 实 当 中 ， 我 们 应 该 对 这 些 技 术 有 正确 的 认识 : 它们 都 是 些 针对 当前 

HTTP 1.1 协议 的 局 限 性 而 采用 的 权宜 之 计 。 我 们 本 来 不 应 该 操心 去 连接 文件 、 拼 合 

图 标 、 分 割 域名 或 幅 入 资源 。 但 遗憾 的 是 ,，“ 不 应 该 ”并 不 是 务实 的 态度 这些 优化 

手段 之 所 以 存在 ， 都 是 有 原因 的 ， 在 背后 的 问题 被 HTTP 的 下 一 个 版 本 解决 之 前 ， 
必须 得 依靠 它们 。 
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让 iTunes 用 户 感受 到 3 倍 以 上 的 性 能 增强 
在 WWDC 2012 上 ，Joshua Graessley 分 享 了 一 个 针对 HTTP 优化 取得 巨大 成 效 的 
案例 : 革 果 工程 师 通过 使 用 HTTP 的 持久 连接 和 管道 ， 重 用 iTunes 中 既 有 的 TCP 
连接 ， 使 得 低 网 速 用 户 的 性 能 提升 到 原来 的 3 信 ! 
很 明显 ， 理 解 HTTP 的 基本 原理 回报 巨大 。 要 了 解 前 面 案例 的 详细 分 析 ， 请 查找 
WWDC 关于 iTunes 的 存档 ， 找 到 Graessley 的 演讲 ， 即 Session 706: Networking 
Best Practices 。 











11.1 持久 连接 的 优点 


HTTP 1.1 的 一 个 主要 改进 就 是 引入 了 持久 HTTP 连接 。 在 9.3 节 “HTTP 1.1: 互联 
网 标准 ”中 ， 我 们 介绍 过 持久 连接 ， 现 在 我 们 再 演示 一 下 为 什么 这 个 特性 对 我 们 的 
优化 策略 如 此 重要 。 

为 简单 起 见 ， 我 们 限定 最 多 只 有 一 个 TCP 连接 ， 并且 只 取得 两 个 小 文件 ( 
<4 KB) : 一 个 HTML 文档 ,一 个 CSS 文件 ， 服 务 器 响应 需要 不 同 的 时 间 (分 
40 ms 和 20 mas ) 。 





每 个 


别 为 








a、 到 11-1 假设 从 纽约 到 伦敦 的 单 向 光纤 延迟 与 表 1-1 中 相同 ， 都 是 28 ms。 














每 个 TCP 连接 开始 都 有 三 次 握手 ， 要 经 历 一 次 客户 端 与 服务 器 间 完 整 的 往返 。 此 
后 ,会 因为 HTTP 请 求 和 响应 的 两 次 通信 而 至 少 引发 另 一 次 往返 。 最 后 ， 还 要 加 上 
服务 器 处 理 时 间 ， 才 能 得 到 每 次 请 求 的 总 时 间 。 


服务 器 处 理 时 间 无 法 预测 ， 因 为 这 个 时 间 因 资源 和 后 端 硬 件 而 异 。 不 过 ， 这 里 的 重 
点 其 实 是 由 一 个 新 TCP 连接 发 送 的 HTTP 请 求 所 花 的 总 时 间 ， 最 少 等 于 两 次 网 络 往 
返 的 时 间 : 一 次 用 于 握手 ， 一 次 用 于 请 求 和 响应 。 这 是 所 有 非 持 久 HTTP 会 话 都 要 
付出 的 固定 时 间 成 本 。 
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TCP 连 接 #1 ， 请 求 #1: HTML 请 求 





客户 端 服务 器 


su 96 - d)1 





服务 器 处 理 时 间 : 40 ms 








sw 96 -dllH 


Pr 152 ms 


TCP 连 接 妃 ， 请 求 夫 :CSS 请 求 





客户 端 服务 器 


su96 -d)l 






服务 器 处 到 





suW 9/~ dllH 





图 1 


1-1: 通过 单独 的 TCP 连接 取得 HTML 和 CSS 文件 


服务 器 处 理 速度 越 快 ， 固 定 延 迟 对 每 个 网 络 请 求 总 时 间 的 影响 就 越 大 ! 要 
4 4 、 验 证 这 一 点 ， 可 以 改 一 改 前 面 例子 中 的 往返 时 间 和 服务 器 处 理 时 间 。 








二 
0 
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实际 上 ， 这 时 候 最 简单 的 优化 就 是 重用 底层 的 连接 ! 添加 对 HITP 持久 连接 的 支持 ， 

就 可 以 避免 第 二 次 TCP 连接 时 的 三 次 握手、 消除 另 一 次 TCP 慢 启 动 的 往返 ， 节 约 

整整 一 次 网 络 延迟 。 

在 我 们 两 个 请 求 的 例子 中 ， 总 共 只 节约 了 一 次 往返 时 间 。 但 是 ， 更 常见 的 情况 是 一 

次 TCP 连接 要 发 送 N 次 HTTP 请 求 ， 这 时 : 

。 没有 持久 连接 ， 每 次 请 求 都 会 导致 两 次 往返 延迟 ，; 

。 有 持久 连接 ， 只 有 第 一 次 请 求 会 导致 两 次 往返 延迟 ， 后 续 请 求 只 会 导致 一 次 往返 
延迟 。 


在 启用 持久 连接 的 情况 下 ,NN 次 请 求 市 省 的 总 延迟 时 间 就 是 (N-1) xRTT。 还 记 
得 吗 ， 前 面 说 过 ， 在 当代 Web 应 用 中 ， 的 平均 值 是 90， 而 且 还 在 继续 增加 (10.2 
节 “ 章 析 现 代 Web 应 用 ”)。 因 此 ， 依 靠 持 久 连 接 节 约 的 时 间 ， 很 快 就 可 以 用 秒 来 衡 
量 了 ! 这 充分 说 明 持 久 化 HTTP 是 每 个 Web 应 用 的 关键 优化 手段 。 








客户 端 和 服务 器 上 的 连接 重用 


好 消息 是 ， 只 要 服务 器 愿意 配合 ， 所 有 现代 浏览 器 都 会 党 试 使 用 持久 化 HITP 连 
接 。 可 以 检查 一 下 自己 的 应 用 和 代理 服务 器 配置 ， 确 保 使 用 持久 连接 。 为 保证 最 
好 的 结果 ， 请 使 用 HTTP 1.1， 因 为 它 默 认 启 用 持久 连接 。 如 果 只 能 使 用 HTTP 
1.0， 则 可 以 明确 使 用 Connection: Keep-Alive 首部 声明 使 用 持久 连接 。 

此 外 ， 还 要 注意 HTTP 库 和 框架 的 默认 行为 ， 因 为 很 多 库 和 框架 经 常会 默认 使 用 
非 持久 连接 ， 这 种 做 法 多 数 源 于 它们 提供 “更 简单 API” 的 理念 。 只 要 使 用 原始 
HTTP 连接 ， 一 定 记 得 重用 它们 : 重用 连接 的 性 能 提升 非常 巨大 | 











11.2 ” HTTP 管道 


持久 HTTP 可 以 让 我 们 重用 已 有 的 连接 来 完成 多 次 应 用 请 求 ， 但 多 次 请 求 必须 严格 
满足 先进 先 出 (FIFO) 的 队列 顺序 : 发送 请 求 ， 等 待 响 应 完成 ， 再 发 送 客 户 端 队列 
中 的 下 一 个 请 求 。HTTP 管道 是 一 个 很 小 但 对 上 述 工 作 流 却 非常 重要 的 一 次 优化 。 
管道 可 以 让 我 们 把 FIFO 队列 从 客户 端 (请 求 队列 ) 迁移 到 服务 器 (响应 队列 )。 


要 理解 这 样 做 的 好 处 ， 我 们 再 看 一 看 图 11-2。 首 先 ， 服 务 器 处 理 完 第 一 次 请 求 后 ， 
会 发 生 了 一 次 完整 的 往返 : 先是 响应 回 传 ， 接 着 是 第 二 次 请 求 。 在 此 期 间 服务 器 空 
闲 。 如 果 服 务 器 能 在 处 理 完 第 一 次 请 求 后 ， 立 即 开始 处 理 第 二 次 请 求 呢 ? 其 至， 如 
果 服 务 器 可 以 并 行 或 在 多 线程 上 或 者 使 用 多 个 工作 进程 ， 同 时 处 理 两 个 请 求 呢 ? 
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TCP 连 接 #1 ， 请 求 #1-2: HTML+CSS 请 求 














客户 端 服务 器 


suW964 - d)l 





SWZ/LL ~- dllH 


服务 器 处 理 时 间 : 20 ms 








228 ms 








11-2: 通过 持久 TCP 连接 取得 HTML 和 CSS 文件 


通过 尽早 分 派 请 求 ， 不 被 每 次 响应 阻塞 ， 可 以 再 次 消除 额外 的 网 络 往返 。 这 样 ， 就 
从 非 持 和 久 连接 状态 下 的 每 个 请 求 两 次 往返 ， 变 成 了 整个 请 求 队列 只 需要 两 次 网 络 往 
返 (图 11-3) | 


增 人 


和 

4 ® 

‘4 
DSN 





HTTP 1.1 管道 的 好 处 ， 主 要 就 是 消除 了 发 送 请 求 和 响应 的 等 待 时 间 。 这 种 
并 行 处 理 请 求 的 能 力 对 提升 应 用 性 能 的 帮助 非常 之 大 。 


现在 我 们 暂停 一 会 ， 回 顾 一 下 在 性 能 优化 方面 的 收获 。 一 开始 ， 每 个 请 求 要 用 两 个 


TCP 连接 ( 


图 11-1)， 总 延迟 为 284 ms。 在 使 用 持久 连接 后 (图 11-2)， 避 免 了 一 








次 握手 往返 ， 总 延迟 减少 为 228 ms。 最 后 ， 通 过 使 用 HTTP 管道 ， 又 减少 了 两 次 请 
求 之 间 的 一 次 往返 ， 总 延迟 减少 为 172 ms。 这 样 ， 从 284 ms 到 172 ms， 这 40% 的 
性 能 提升 完全 拜 简单 的 协议 优化 所 赐 。 
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—— 
SW95 -d)l 





swW 91L- dllH 











图 11-3; 使 用 HTTP 管道 发 送 请 求 ， 服 务 器 端 按 FIFO 处 理 队列 


而 且 ， 这 40% 的 性 能 提升 还 不 是 固定 不 变 的 。 这 个 数字 与 我 们 选择 的 网 络 延迟 和 两 
个 请 求 的 例子 有 关 。 和 希望 读者 自己 能 够 尝试 一 些 不 同 的 情况 ， 比 如 延迟 更 高 、 请 求 
更 多 的 情况 。 尝 试 之 后 ， 你 会 惊讶 于 性 能 提升 效果 比 这 里 还 要 高 得 多 。 事 实 上 ， 网 
络 延迟 越 高 ， 请 求 越 多 ， 节 省 的 时 间 就 越 多 。 我 觉得 大 家 很 有 必要 自己 动手 验证 一 
下 这 个 结果 。 因 此 ， 越 是 大 型 应 用 ， 网 络 优化 的 影响 越 大 。 


不 过 ， 这 还 不 算 完 。 眼 光敏 锐 的 读者 可 能 已 经 发 现 了 ， 我 们 可 以 在 服务 器 上 并 行 处 
理 请 求 。 理 论 上 讲 ， 没 有 障碍 可 以 阻止 服务 器 同时 处 理 管道 中 的 请 求 ， 从 而 再 减少 
20 ms 的 延迟 。 


可 惜 的 是 ， 当 我 们 想 要 采取 这 个 优化 措施 时 ， 发 现 了 HTTP 1.x 协议 的 一 些 局 限 性 。 
HTTP 1.x 只 能 严格 串 行 地 返回 响应 。 特 别 是 ，HTTP 1.x 不 允许 一 个 连接 上 的 多 个 
响应 数据 交错 到 达 (多 路 复 用 )， 因 而 一 个 响应 必须 完全 返回 后 ， 下 一 个 响应 才 会 开 
始 传 输 。 为 说 明 这 一 点 ， 我 们 可 以 看 看 服务 器 并 行 处 理 请 求 的 情况 (图 11-4)。 
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客户 端 服务 器 


SUl96 d)1 





su196 dllH 














11-4: 使 用 HTTP 管道 发 送 请 求 ， 且 服务 器 端 并 行 处 理 
图 11-4 演示 了 如 下 儿 个 方面 : 


。 HTML 和 CSS 请求 同 时 到 达 ， 但 先 处 理 的 是 HTML 请 求 ; 

。 服务 器 并 行 处 理 两 个 请 求 ， 其 中 处 理 HTML 用 时 40 ms， 处 理 CSS 用 时 20 ms; 
。 CSS 请 求 先 处 理 完 成 ， 但 被 缓冲 起 来 以 等 候 发 送 HTML 响应 ; 

。 发 送 完 HTML 响应 后 ， 再 发 送 服务 器 缓冲 中 的 CSS 响应 。 


即使 客户 端 同时 发 送 了 两 个 请 求 ， 而 且 CSS 资源 先 准备 就 绪 ， 服 务 器 也 会 先 发 送 
HTML 响应 ， 然 后 再 交付 CSS。 这 种 情况 通常 被 称 作 队 首 阻塞 ， 并 经 党 导致 次 优化 
交付 : 不 能 充分 利用 网 络 连接 ， 造 成 服务 器 缓冲 开销 ， 最 终 导 致 无 法 预测 的 客户 端 
延迟 。 假 如 第 一 个 请 求 无 限期 挂 起 ， 或 者 要 花 很 长 时 间 才 能 处 理 完 ， 怎 么 办 呢 ? 在 
HTTP 1.1 中 ， 所 有 后 续 的 请 求 都 将 被 阻塞 ， 等 待 它 完成 。 








在 前 面 讨 论 TCP 时 ， 我 们 已 经 提 到 过 队 首 阻塞 的 问题 了 。 由 于 TCP 要 求 
心 | 严格 按照 顺序 交付 ， 丢 失 一 个 TCP 分 组 就 会 阻塞 所 有 高 序号 的 分 组 ， 除 非 
属 ， 重 传 那个 丢失 的 分 组 ， 这 样 就 会 导致 额外 的 应 用 延迟 ， 详 细 情 况 请 参考 2.4 

节 “ 队 首 阻塞 ”。 











实际 中 ， 由 于 不 可 能 实现 多 路 复 用 ，HTTP 管道 会 导致 HTTP 服务 器 、 代 理 和 客户 
端 出 现 很 多 微妙 的 ， 不 见 文档 记载 的 问题 : 
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。 一 个 慢 响应 就 会 阻塞 所 有 后 续 请 求 ， 

。 并 行 处 理 请 求 时 ， 服 务 器 必须 缓冲 管道 中 的 响应 ， 从 而 占用 服务 器 资源 ， 如 果 有 
个 响应 非常 大 ， 则 很 容易 形成 服务 器 的 受 攻 击 面 ; 

。 响应 失败 可 能 终止 TCP 连接 ， 从 页 强迫 客户 端 重新 发 送 对 所 有 后 续 资源 的 请 求 ， 
导致 重复 处 理 ， 

。 由 于 可 能 存在 中 间 人 代理， 因此 检测 管道 兼容 性 ， 确 保 可 靠 性 很 重要 ， 

。 如 果 中 间 代 理 不 支持 管道 ， 那 它 可 能 会 中 断 连 接 , 也 可 能 会 把 所 有 请 求 串联 起 来 。 


由 于 存在 这 些 以 及 其 他 类 似 的 问题 ， 而 HTTP 1.1 标准 中 也 未 对 此 做 出 说 明 ， 
HTTP 管道 技术 的 应 用 非常 有 限 ， 虽 然 其 优点 考 庸 置疑 。 今 天， 一 些 支 持 管道 的 浏 
览 器 ， 通 常 都 将 其 作为 一 个 高 级 配置 选项 ， 但 大 多 数 浏览 器 都 会 禁用 它 。 换 名 话 
说 ， 如 果 浏 览 器 是 Web 应 用 的 主要 交付 工具 ， 那 还 是 很 难 指望 通过 HTTP 管道 来 
提升 性 能 。 


II 
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在 浏览 器 外 部 使 用 HTTP 管道 

完全 忽略 HTTP 管道 的 优点 之 前 ， 有 必要 提醒 一 下 大 家 ， 如 果 你 对 客户 端 和 服 
务 器 拥有 完全 榨 制 的 权限 ， 那 么 还 是 可 以 使 用 它 的 ， 并 且 效 果 非 常 好 。 事 实 上 ， 
苹果 iTunes 那个 案例 就 说 明了 问题 ， 参 见 本 章 开 头 的 “让 iTunes 用 户 感受 到 3 倍 
以 上 的 性 能 增强 ”。 如 此 巨大 的 性 能 提升 ， 就 来 自 启用 持久 HTTP 连接 ， 以 及 在 服 
务 器 和 iTunes 客户 端 内 启用 HTTP 管道 。 
要 在 你 自己 的 应 用 中 局 用 管道 ， 要 注意 如 下 事项 : 
。 确保 HTTP 客户 阁 支 持 管 道 ; 
。 确保 HTTP 服务 器 支持 管道 ; 
。 应 用 必须 处 理 中 断 的 连接 并 恢复 ; 
。 应 用 必须 处 理 中 断 请 求 的 震 等 问题 ; 
。 应 用 必须 保护 自身 不 受 出 问题 的 代理 的 影响 。 
实践 中 部 署 HTTP 管道 的 最 佳 途径 ， 就 是 在 客户 端 和 服务 器 间 使 用 安全 通道 
(HTTPS)。 这 样 ， 就 能 可 靠 地 避免 那些 不 理解 或 不 支持 管道 的 中 间 代 理 的 干扰 。 











11.3 ”使 用 多 个 TCP 连 接 


由 于 HTTP 1.x 不 支持 多 路 复 用 ， 浏 览 器 可 以 不 假 思索 地 在 客户 端 排队 所 有 HTTP 
请 求 ， 然 后 通过 一 个 持久 连接 ， 一 个 接 一 个 地 发 送 这 些 请 求 。 然 而 ， 这 种 方式 在 实 
践 中 太 慢 。 实 际 上 ， 浏 览 器 开发 商 没 有 别 的 办 法 ， 只 能 允许 我 们 并 行 打开 多 个 TCP 
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会 话 。 多 少 个 ? 现实 中 ， 大 多 数 现 代 浏 览 器 ， 包 括 桌 面 和 移动 浏览 器 ， 都 支持 每 个 
主机 打开 6 个 连接 。 


进一步 讨论 之 前 ， 有 必要 先 想 一 想 同 时 打开 多 个 TCP 连接 意味 着 什么 。 当 然 ， 有 正 
面 的 也 有 负面 的 。 下 面 我 们 以 每 个 主机 打开 最 多 6 个 独立 连接 为 例 : 


。 客户 端 可 以 并 行 分 派 最 多 6 个 请 求 ， 
。 服务 器 可 以 并 行 处 理 最 多 6 个 请 求 ， 
。 第 一 次 往返 可 以 发 送 的 累计 分 组 数量 〈TCP cwnd) 增长 为 原来 的 6 倍 。 


在 没有 管道 的 情况 下 ， 最 大 的 请 求 数 与 打开 的 连接 数 相 同 。 相 应 地 ，TCP 拥塞 窗口 
也 要 乘 以 打开 的 连接 数量 ， 从 而 允许 客户 端 绕 开 由 TCP 慢 局 动 规定 的 分 组 限制 。 这 
好 像 是 一 个 方便 的 解决 方案 。 我 们 再 看 看 这 样 做 的 代价 : 


。 更 多 的 套 接 字 会 占用 客户 端 、 服 务 器 以 及 代理 的 资产， 包括 内 存 缓冲 区 和 CPU 
时 钟 周期 ， 

。 并 行 TCP 流 之 间 竞 争 共享 的 带宽 ， 

。 由 于 处 理 多 个 套 接 字 ， 实 现 复杂 性 更 高 ， 

。 即使 并 行 TCP 流 ， 应 用 的 并 行 能 力也 受 限 制 。 


实践 中 ，CPU 和 内 存 占用 并 非 微不足道 ， 由 此 会 导致 客户 端 和 服务 器 端的 资产 占用 
量 上 升 ， 运 维 成 本 提高 。 类 似 地 ， 由 于 客户 端 实现 的 复杂 性 提高 ， 开 发 成 本 也 会 提 
高 。 最 后 ， 说 到 应 用 的 并 行 性 ， 这 种 方式 提供 的 好 处 还 是 非常 有 限 的 。 这 不 是 一 个 
长 期 的 方案 。 了 解 这 些 之 后 ， 可 以 说 今天 之 所 以 使 用 它 ， 主 要 有 三 个 原因 : 


(1) 作为 绕 过 应 用 协议 (HTTP) 限制 的 一 个 权宜 之 计 ， 
(2) 作为 绕 过 TCP 中 低 起 始 拥塞 窗口 的 一 个 权宜 之 计 ; 

(3) 作为 让 客户 端 绕 过 不 能 使 用 TCP 窗口 缩放 的 一 个 权宜 之 计 (参见 2.3 证 “带宽 
延迟 积 ”)。 


后 两 个 针对 TCP 的 问题 (窗口 缩放 和 cwnd) 最 好 是 通过 升级 到 最 新 的 OS 内 核 来 
解决 ， 参 见 2.5 节 “ 针 对 TCP 的 优化 建议 ”。cwnd 值 最 近 又 提高 到 了 10 个 分 组 ， 
而 所 有 最 新 的 平台 都 能 可 靠 地 支持 TCP 窗口 缩放 。 这 当然 是 好 消息 。 但 坏 消息 是 ， 
没有 更 好 办 法 绕 开 HTTP 1.x 的 多 路 复 用 问题 。 


只 要 必须 支持 HTTP 1.x 客 户 端 ， 就 不 得 不 想 办 法 应 对 多 TCP 流 的 问题 。 而 这 又 会 
带 来 一 个 明显 的 问题 : 为 什么 浏览 器 要 规定 每 个 主机 6 个 连接 呢 ? 了 臣 怕 有 读者 也 猜 
到 了 ， 这 个 数字 是 多 方 平衡 的 结果 : 这 个 数字 越 大 ， 客 户 端 和 服务 器 的 资源 占用 越 
多 ， 但 随 之 也 会 带 来 更 高 的 请 求 并 行 能 力 。 每 个 主机 6 个 连接 只 不 过 是 大 家 都 觉得 
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比较 安全 的 一 个 数字 。 对 某 些 站 点 而 言 ， 这 个 数字 已 经 足够 了 ， 但 对 其 他 站 点 来 说 ， 
可 能 还 满足 不 了 需求 。 





消耗 客户 端 和 服务 器 资源 
限制 每 个 主机 最 多 6 个 连接 ， 可 以 让 浏览 器 检测 出 无 意 (或 有 意 ) 的 DoS (Denial 
of Service) 攻击 。 如 果 没有 这 个 限制 ， 客 户 问 有 可 能 消耗 掉 服务 器 的 所 有 资源 。 


讽刺 的 是 ， 同 样 的 安全 检测 在 某 些 浏览 器 上 却 会 招致 反 向 攻击 : 如 果 客 户 端 超过 
了 最 大 连接 数 ， 那 么 所 有 后 来 的 客户 问 请 求 都 将 被 阻塞 。 大 家 可 以 做 个 试验 ， 在 
一 个 主机 上 同时 打开 6 个 并 行 下 载 ， 然 后 再 打开 第 7 个 下 载 请 求 ， 这 个 请 求 会 挂 
起 ， 直 到 前 面 的 请 求 完 成 才 会 执行 。 

用 足 客户 端 连 接 的 限制 似乎 是 一 个 可 以 接受 的 安全 问题 ， 但 对 于 需要 实时 交付 数 
据 的 应 用 而 言 ， 这 样 做 越 来 越 容易 造成 部 署 上 的 问题 。 比 如 WebSocket、Server 
Sent Event 和 挂 起 XHR， 这 些 会 话 都 会 占用 整整 一 个 TCP 流 ， 而 不 管 有 无 数据 传 
输 记 住 ， 没 有 多 路 复 用 一 说 | 实际 上 ， 如 果 你 不 注意 ， 那 很 可 能 自己 对 自己 
的 应 用 施加 DoS 攻击 。 














11.4 域名 分 区 


HTTP 1.x 协议 的 一 项 空白 强迫 浏览 器 开发 商 引 入 并 维护 着 连接 池 ， 每 个 主机 最 多 6 
个 TCP 流 。 好 的 一 方面 是 对 这 些 连接 的 管理 工作 都 由 浏览 器 来 处 理 。 作 为 应 用 开发 
者 ， 你 根本 不 必修 改 自 己 的 应 用 。 不 好 的 一 方面 呢 ， 就 是 6 个 并 行 的 连接 对 你 的 应 
用 来 说 可 能 仍然 不 够 用 。 


根据 HTTP Archive 的 统计 ， 目 前 平均 每 个 页 面 都 包含 90 多 个 独立 的 资源 ， 如 有 果 这 
些 资源 都 来 自 同一 个 主机 ， 那 么 仍然 会 导致 明显 的 排队 等 待 (图 11-5) 。 实 际 上 ， 
何必 把 自己 只 限制 在 一 个 主机 上 呢 ? 我 们 不 必 只 通过 一 个 主机 (例如 www.example. 
com) 提供 所 有 资源 ， 而 是 可 以 手工 将 所 有 资源 分 散 到 多 个 子 域名 : {shard1， 
shardn}.example.com。 由 于 主机 名 称 不 一 样 了 ， 就 可 以 突破 浏览 器 的 连接 限制 ， 实 
现 更 高 的 并 行 能 力 。 域 名 分 区 使 用 得 越 多 ， 并 行 能 力 就 越 强 ! 

当然 ， 天 下 没有 免费 的 午餐 ， 域 名 分 区 也 不 例外 : 每 个 新 主机 名 都 要 求 有 一 次 额外 
的 DNS 查询， 每 多 一 个 套 接 字 都 会 多 消耗 两 端的 一 些 资 源 ， 而 更 精 糕 的 是 ， 站 点 作 
者 必须 手工 分 离 这 些 资源 ， 并 分 别 把 它们 托管 到 多 个 主机 上 。 
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本 Elements Resources | Network | Sources Timeline Profiles Audits Console PageSpeed 

















Name Method Status Type rm Start Time i i i 755 ms 
国 localhost GET 200 text/html | | 区 l7ms ® i 
01jpeg GET 202 image/jpeg ... ... 242ms mm 
口 02jpeg CET 202 image/jpeg ... ... 243 ms CD 
03jpeg CET 202 image/jpeg ... ... 242 ms CD ， 
口 04jpeg GET 202 image/jpeg ... ... 241ms 让 
回 05jpeg GET 202 image/jpeg ... ... 235ms em er 
口 06jpeg GET 202 image/jpeg ... ... 235ms AS 
口 07jpeg GET 202 image/jpeg ... ... 475ms yy 
口 08jpeg GET 202 image/jpeg ... ... S63ms 0 
09jpeg GET 202 image/jpeg ... ... 561 ms VE 
口 10jpeg GET 202 image/jpeg ... ... 561 ms Pe 
11jpeg GET 202 image/jpeg ... ... 561 ms ED 
口 12jpeg GET 202 image/jpeg ... ... 561 ms ED 

















图 11-5: 由 于 每 个 主机 只 能 同时 发 起 6 个 连接 而 导致 的 资源 错 列 


。 到 同一 个 下 地 址 是 很 常见 的 做 法 。 所 有 分 区 都 通过 CNAME DNS 记录 指 
”向 同一 个 服务 器 ， 而 浏览 器 连接 限制 针对 的 是 主机 名 ， 不 是 全 地 址 。 另 
外 ， 每 个 分 区 也 可 以 指向 一 个 CDN 或 其 他 可 以 访问 到 的 服务 器 。 


| 实践 中 ， 把 多 个 域名 (如 shardl.example.com、shard2.example.com) 解析 
A 
Me 














怎么 计算 最 优 的 分 区 数目 呢 ? 这 个 问题 不 好 回答 ， 因 为 没有 简单 的 方程 式 。 答 案 取决 
于 页 面 中 资源 的 数量 (每 个 页 面 都 可 能 不 一 样 )， 以 及 客户 pe ee 
( 因 客 户 端 而 异 )。 实 际 上 ， 我 们 能 做 的 ， 就 是 在 调查 的 基础 上 做 出 预测 ， 然 后 使 用 固 
定数 量 的 分 区 。 幸 运 的 话 ， 多 这 么 一 点 复杂 性 ， 还 是 能 给 ww 


实践 中 ， 域 名 分 区 经 常会 被 滥用 ， 导 致 几 十 个 TCP 流 都 得 不 到 充分 利用 ， 其 中 很 多 
永远 也 避免 不 了 TCP 慢 启 动 ， 最 坏 的 情况 下 还 会 降低 性 能 。 此 外 ， 如 果 使 用 的 是 
HTTPS， 那 么 由 于 TLS 握手 导致 的 额外 网 络 往返 ， 会 使 得 上 述 代价 更 高 。 此 时 ， 请 
大 家 注意 如 下 几 条 : 


。 首先 ， 把 TCP 利用 好 ， 参 见 2.5 节 “ 针 对 TCP 的 优化 建议 ”; 

。 浏览 器 会 自动 为 你 打开 6 个 连接 ， 

。 资源 的 数量 、 大 小 和 响应 时 间 都 会 影响 最 优 的 分 区 数目 ; 

。 客户 端 延迟 和 带宽 会 影响 最 优 的 分 区 数目 ， 

。 域名 分 区 会 因为 额外 的 DNS 查询 和 TCP 慢 启动 而 影响 性 全 

域名 分 区 是 一 种 合理 但 又 不 完美 的 优化 手段 。 请 大 家 一 定 先 从 最 小 分 区 数目 〈 不 分 


区 ) 开始 ， 然 后 逐个 增加 分 区 并 度量 分 区 后 对 应 用 的 影响 。 现 实 当 中 ， 真 正 因 同 时 
打开 十 儿 个 连接 而 提升 性 能 的 站 点 并 不 多 ， 如 果 你 最 终 使 用 了 很 多 分 区 ， 那 么 你 会 
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发 现 减少 资源 数量 或 者 将 它们 合并 为 更 少 的 请 求 ， 反 而 能 带 来 更 大 的 好 处 。 
二 人， 
as DNS 查询 和 TCP 慢 启动 导致 的 额外 消耗 对 高 延迟 客户 端的 影响 最 大 。 换 
rw 。 名 话说， 移动 (3G、4G) 客户 端 经 常 是 受过 度 域名 分 区 影响 最 大 的 ! 
a 


增 
b>, 








11.5 ”度量 和 控制 协议 开销 

HTTP 0.9 当初 就 是 一 个 简单 的 只 有 一 行 的 ASCII 请 求 ， 用 于 取得 一 个 超 文 本 文 
档 ， 这 样 导 致 的 开销 是 最 小 的 。HTTP 1.0 增加 了 请 求 和 响应 首部 ， 以 便 双 方 能 够 
交换 有 关 请 求 和 响应 的 元 信息 。 最 终 ，HTTP 1.1 把 这 种 格式 变 成 了 标准 : 服务 器 
和 客户 端 都 可 以 轻松 扩展 首部 ， 而 且 始 终 以 纯 文 本 形式 发 送 ， 以 保证 与 之 前 HTTP 
版 本 的 兼容 。 


今天 ， 每 个 浏览 器 发 起 的 HTTP 请 求 ， 都 会 携带 额外 500~800 字 节 的 HITP 元 数 
据 : 用 户 代理 字符 串 、 很 少 改 变 的 接收 和 传输 首部 、 缓 存 指令 ， 等 等 。 有 时 候 ，500~ 
800 字 节 都 少 说 了 ， 因 为 没有 包含 最 大 的 一 块 : HTTP cookie。 现 代 应 用 经 常 通过 
cookie 进行 会 话 管理 、 记 录 个 性 选项 或 者 完成 分 析 。 综 合 到 一 起 ， 所 有 这 些 未 经 压 
缩 的 HTTP 元 数据 经 常会 给 每 个 HTTP 请 求 增 加 几 千 字 节 的 协议 开销 。 


RFC 2616 (HTTP 1.1) 没有 对 HTTP 首部 的 大 小 规定 任何 限制 。 然 而 ， 实 际 
4 4 ， 中 ， 很 多 服务 器 和 代理 都 会 将 其 限制 在 8 KB 或 16 KB 之 内 。 


4 



































HTTP 首部 的 增多 对 它 本 身 不 是 坏事 ， 因 为 大 多 数 首部 都 有 其 特定 用 途 。 然 而 ， 由 
于 所 有 HTTP 首部 都 以 纯 文 本 形式 发 送 〈 不 会 经 过 任何 压 绑 )， 这 就 会 给 每 个 请 
求 附加 较 高 的 额外 负荷 ， 而 这 在 某 些 应 用 中 可 能 造成 严重 的 性 能 问题 。 举 个 例子 ， 
API 驱动 的 Web 应 用 越 来 越 多 ， 这 些 应 用 需要 频繁 地 以 序列 化 消息 (如 JSON) 的 
形式 通信 。 在 这 些 应 用 中 ， 额 外 的 HTTP 开销 经 常会 超过 实际 传输 的 数据 静 荷 一 个 
数量 级 : 




















$> curl --trace-ascii - -d'{"msg":"hello"}' http://www.igvita.com/api 


== Info: Connected to www.igvita.com 

=> Send header, 218 bytes © 

POST /api HTTP/1.1 

User-Agent: curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 ... 
Host: www.igvita.com 

Accept: */* 

Content-Length: 15 2 
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Content-Type: application/x-www-form-urlencoded 
=> Send data，15 bytes (0xf) 
{"msg" : "hello"} 


<= Recv header, 134 bytes © 

HTTP/1.1 204 No Content 

Server: nginx/1.0.11 

Via: HTTP/1.1 GWA 

Date: Thu, 20 Sep 2012 05:41:30 GMT 

Cache-Control: max-age=0, no-cache 
@ HTTP 请 求 首 部 : 218 字 节 
@ 应 用 静 荷 15 字 节 ({"msg":"hello"}) 
@ 服务 器 的 204 响应 : 134 字 节 


在 前 面 的 例子 中 ， 室 室 15 个 字符 的 JSON 消息 被 352 字 节 的 HTTP 首部 包 衷 着 ， 全 
部 以 纯 文本 形式 发 送 一 一 协议 字 节 开销 占 96%， 而 且 这 还 是 没有 cookie 的 最 好 情 
况 。 减 少 要 传输 的 首部 数据 (高 度 重复 且 未 压缩 )， 可 以 市 省 相当 于 一 次 往返 的 延迟 
时 间 ， 显 著 提 升 很 多 Web 应 用 的 性 能 。 














5 
Cookie 在 很 多 应 用 中 都 是 常见 的 性 能 瓶颈 ， 很 多 开发 者 都 会 包 略 它 给 每 
心 次 请 求 增 加 的 额外 负担 。 相 关 讨 论 请 参见 13.1.3 节 “ 消 除 不 必要 的 请 求 


0 -EL 
"snl 








11.6 连接 与 拼合 


最 快 的 请 求 是 不 用 请 求 。 不 管 使 用 什么 协议 ， 也 不 管 是 什么 类 型 的 应 用 ， 减 少 请 求 
次 数 总 是 最 好 的 性 能 优化 手段 。 可 是 ， 如 果 你 无 论 如 何 也 无 法 减少 请 求 ， 那 么 对 
HTTP 1.x 而 言 ， 可 以 考虑 把 多 个 资源 捆绑 打包 到 一 块 ， 通 过 一 次 网 络 请 求 获取 : 


。 连接 
把 多 个 JavaScript 或 CSS 文件 组 合 为 一 个 文件 。 


。 拼合 


把 多 张 图 片 组 合 为 一 个 更 大 的 复合 的 图 片 。 


对 JavaScript 和 CSS 来 说 ， 只 要 保持 一 定 的 顺序 ， 就 可 以 做 到 把 多 个 文件 连接 起 来 
而 不 影响 代码 的 行为 和 执行 。 类 似 地 ， 多 张 图 片 可 以 组 合 为 一 个 “图 片 精灵 ”， 然 后 
使 用 CSS 选择 这 张大 图 中 的 适当 部 分 ， 显示 在 浏览 器 中 。 这 两 种 技术 都 具备 两 方面 
的 优点 。 
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。 碱 少 协议 开销 
通过 把 文件 组 合成 一 个 资源 ， 可 以 消除 与 文件 相关 的 协议 开销 。 如 前 所 述 ， 每 个 
文件 很 容易 招致 KB 级 未 压缩 数据 的 开销 。 

















。 应 用 层 管道 
说 到 传输 的 字 节 ， 这 两 种 技术 的 效果 都 好 像 是 启用 了 HTTP 管道 来 自 多 个 响应 
的 数据 前 后 相继 地 连接 在 一 起 ， 消 除了 额外 的 网 络 延迟 。 实 际 上 ， 就 是 把 管道 提 
高 了 一 层 ， 置 和 人 了 应 用 中 。 


连接 和 拼合 技术 都 属于 以 内 容 为 中 心 的 应 用 层 优化 ， 它 们 通过 减少 网 络 往返 开销 ， 
可 以 获得 明显 的 性 能 提升 。 可 是 ， 实 现 这 些 技术 也 要 求 额外 的 处 理 、 部 署 和 编码 
(比如 选择 图 片 精灵 中 子 图 的 CSS 代码 )， 因 而 也 会 给 应 用 带 来 额外 的 复杂 性 。 此 
外 ， 把 多 个 资源 打包 到 一 块 ， 也 可 能 给 缓存 带 来 负担 ， 影 响 页 面 的 执行 速度 。 


要 理解 为 什么 这 些 技 术 会 伤害 性 能 ， 可 以 考虑 一 种 并 不 少见 的 情况 : 一 个 包含 十 来 


个 JavaScript 和 CSS 文件 的 应 用 ， 在 产品 状态 下 把 所 有 文件 合并 为 一 个 CSS 文件 和 
一 个 JavaScript 文件 。 

















。 相同 类 型 的 资源 都 位 于 一 个 URL (缓存 键 ) 下 面 。 

。 资源 包 中 可 能 包含 当前 页 面 不 需要 的 内 容 。 

。 对 资源 包 中 任何 文件 的 更 新 ,都 要 求 重 新 下 载 整个 资源 包 ， 导 致 较 高 的 字 节 开销 。 

。 JavaScript 和 CSS 只 有 在 传输 完成 后 才能 被 解析 和 执行 ， 因 而 会 拖 慢 应 用 的 执行 
速度 。 


实践 中 ， 大 多 数 Web 应 用 都 不 是 只 有 一 个 页 面 ， 而 是 由 多 个 视图 构成 。 每 个 视图 都 
有 自己 的 资源 ， 同 时 资源 之 间 还 有 部 分 重合 公用 的 CSS、JavaScript 和 图 片 。 实 
际 上 ， 把 所 有 资源 都 组 合 到 一 个 文件 经 常会 导致 处 理 和 加 载 不 必要 的 字 节 。 虽 然 可 
以 把 它 看 成 一 种 预 获取 ， 但 代价 则 是 降低 了 初始 启动 的 速度 。 


对 很 多 应 用 来 说 ， 更 新 资源 带 来 的 问题 更 大 。 更 新 图 片 精灵 或 组 合 JavaScript 文件 
中 的 某 一 处 ， 可 能 就 会 导致 重新 传输 几 百 KB 数据 。 由 于 牺牲 了 模块 化 和 缓存 粒度 ， 
假如 打包 资源 变动 频率 过 高 ， 特 别 是 在 资源 包 过 大 的 情况 下 ， 很 快 就 会 得 不 偿 失 。 
如 果 你 的 应 用 真 到 了 这 种 境地 ， 那 么 可 以 考虑 把 “稳定 的 核心 "， 比 如 框架 和 库 ， 转 
移 到 独立 的 包 中 。 


内 存 占用 也 会 成 为 问题 。 对 图 片 精灵 来 说 ， 浏 览 器 必须 分 析 整 个 图 片 ， 即 便 实 际 上 
只 显示 了 其 中 的 一 小 块 ， 也 要 始终 把 整个 图 片 都 保存 在 内 存 中 。 浏 览 器 是 不 会 把 不 
显示 的 部 分 从 内 存 中 剔除 掉 的 ! 
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计算 图 片 对 内 存 的 需求 
所 有 编码 的 图 片 经 浏览 器 解析 后 都 会 以 RGBA 位 图 的 形式 保存 于 内 存 当 中 。 每 个 
RGBA 图 片 的 像素 需要 占用 4 字 节 : 红 、 绿 、 蓝 通道 各 占 1 字 节 ，Alpha (延明 ) 
通道 占 1 字 节 。 这 样 算 下 来 ， 一 张 图 片 占 用 的 内 存量 就 是 图 片 像素 宽度 x 像素 高 
度 x4 字 节 。 
举 个 例子 ，800 x 600 像素 的 位 图 会 占 多 大 内 存 呢 ? 
800 x 600 x 4B=1920000B = 1.83 MB 
在 资源 受 限 的 设备 ， 比 如 手机 上 ， 内 存 占用 很 快 就 会 成 为 瓶颈 。 对 于 游戏 等 严重 
依赖 图 片 的 应 用 来 说 ， 这 个 问题 就 会 更 明显 。 








最 后 ， 为 什么 执行 速度 还 会 受 影响 呢 ? 我 们 知道 ， 浏 览 器 是 以 递增 方式 处 理 
HTML 的 ， 而 对 于 JavaScript 和 CSS 的 解析 及 执行 ， 则 要 等 到 整个 文件 下 载 完 毕 。 
JavaScript 和 CSS 处 理 器 都 不 允许 递增 式 执行 。 





CSS 和 JavaScript 文件 大 小 与 执行 性 能 

CSS 文件 越 大 ， 浏 览 器 在 构建 CSSOM 前 经 历 的 阻塞 时 间 就 越 长 ， 从 而 推迟 首次 
绘制 页 面 的 时 间 。 类 似 地 ，JavaScript 文件 越 大 ， 对 执行 速度 的 影响 同样 越 大 ; 小 
文件 倒是 能 实现 “递增 式 ” 执 行 。 

打包 文件 到 底 多 大 合适 呢 ? 可 惜 的 是 ， 没 有 理想 的 大 小 。 然 而 ， 谷 歌 PageSpeed 
团队 的 测试 表明 ，30~50 KB (压缩 后 ) 是 每 个 JavaScript 文件 大 小 的 合适 范围 : 
既 大 到 了 能 够 减少 小 文件 带 来 的 网 络 延迟 ， 还 能 确保 递增 及 分 层 式 的 执行 。 具 体 
的 结果 可 能 会 由 于 应 用 类 型 和 脚本 数量 而 有 所 不 同 。 








总 之 ， 连 接 和 拼合 是 在 HTTP 1.x 协议 限制 (管道 没有 得 到 普遍 支持 ， 多 请 求 开 销 
大 ) 的 现实 之 下 可 行 的 应 用 层 优 化 。 使 用 得 当 的 话 ， 这 两 种 技术 可 以 带 来 明显 的 性 
能 提升 ， 代 价 则 是 增加 应 用 的 复杂 度 ， 以 及 导致 缓 在、 更新、 执行 速度 ， 甚 至 谊 染 
页 面 的 问题 。 应 用 这 两 种 优化 时 ， 要 注意 度量 结果 ， 根 据 实际 情况 考虑 如 下 问题 。 


。 你 的 应 用 在 下 载 很 多 小 型 的 资源 时 是 否 会 被 阻塞 ? 
。 有 选择 地 组 合 一 些 请 求 对 你 的 应 用 有 没有 好 处 ? 
。 放弃 缓存 粒度 对 用 户 有 没有 负面 影响 ? 

。 组 合 图 片 是 否 会 占用 过 多 内 存 ? 

。 首次 泻 染 时 是 否 会 遭遇 延迟 执行 ? 


在 上 述 问 题 的 答案 间 求 得 平衡 是 一 种 艺术 。 
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优化 Gmail 性 能 
Gmail 使 用 了 大 量 JavaScript， 而 且 也 不 断 拓 展 了 现代 浏览 器 的 性 能 边界 。 要 提升 
首次 加 载 性 能 ，Gmail 团队 尝试 了 各 种 技术 ， 目 前 包括 如 下 这 些 : 
。 把 首次 绘制 所 需 的 CSS 单独 拿 出 来 ， 优 先 于 其 他 CSS 文件 发 送 ; 
。 递增 地 交付 较 小 的 JavaScript 块 ， 以 实现 递增 式 执行 ; 
。 使 用 定制 的 外 部 更 新 机 制 ， 即 客户 端 在 后 人 台 下 载 新 的 JavaScript 文件 ， 然 后 
在 页 面 刷新 时 更 新 。 


鉴于 Gmail 如 此 庞大 的 用 户 数量 ， 如 果 所 有 打开 的 浏览 器 都 要 更 新 脚本 ， 那 哪怕 
一 次 简单 的 JavaScript 更 新 ， 都 可 能 演变 为 一 次 自残 式 的 DoS 攻击 。 为 此 ，Gmail 
会 在 用 户 使 用 旧版 本 页 面 时 ， 在 后 台 预 先 加 载 更 新 文件 ， 这 样 既 可 以 分 散 负 荷 ， 
又 能 提升 下 一 次 刷新 时 的 速度 。 这 个 过 程 每 天 都 重复 不 止 一 次 。 

在 此 基础 上 ,为 了 让 用 户 感 觉 第 一 次 加 载 的 速度 很 快 ，Gmail 团队 还 在 HTML 文档 
中 说 入 了 关键 性 CSS 和 JavaScript， 然 后 以 块 的 形式 递增 加 载 其 余 JavaScript 文件 ， 
以 加 快 脚 本 执行 一 一 第 一 次 打开 Gmail 时 显示 的 进度 条 ， 反 映 的 就 是 这 个 过 程 | 











11.7 骨 入 资源 

嵌入 资源 是 另 一 种 非常 流行 的 优化 方法 ， 把 资源 姐 入 文档 可 以 减少 请 求 的 次 
数 。 比 如 ，JavaScript 和 CSS 代码 ， 通 过 适当 的 script 和 style 块 可 以 直接 放 在 
页 面 中 ， 而 图 片 甚至 音频 或 PDF 文件 ， 都 可 以 通过 数据 URI (data:[mediatype] 
[;base64] ,data) 的 方式 戏 入 到 页 面 中 : 








<img src="data:image/gif;base64,ROLGODLNAQABAIAAAAA 
AAAAAACHS5BAAAAAAALAAAAAABAAEAAAICTAEAOw==" 
alt="1x1 transparent (GIF) pixel" /> 


前 面 的 例子 是 在 文档 中 矢 入 了 一 个 1x1 的 透明 GIF 像素 。 而 任何 MIME 
心 类 型 ， 只 要 浏览 器 能 理解 ， 都 可 以 通过 类 似 方式 代入 到 页 面 中 ， 包 括 
PDF、 音 频 、 视 频 。 不 过 ， 有 些 浏 览 器 会 限制 数据 URI 的 大 小 ， 比 如 IE8 
最 大 只 允许 32 KB。 








数据 URI 适合 特别 小 的 ， 理 想 情况 下 ， 最 好 是 只 用 一 次 的 资源 。 以 向 入 方式 放 到 页 
面 中 的 资源 ， 应 该 算是 页 面 的 一 部 分 ， 不 能 被 浏览 器 、CDN 或 其 他 缓存 代理 作为 单 
独 的 资源 缓存 。 换 句 话 说 ， 如 果 在 多 个 页 面 中 都 黎 入 同样 的 资源 ， 那 么 这 个 资源 将 
会 随 着 每 个 页 面 的 加 载 而 被 加 载 ， 从 而 增 大 每 个 页 面 的 总 体 大 小 。 另 外 ， 如 果 艇 入 
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资源 被 更 新 ， 那 么 所 有 以 前 出 现 过 它 的 页 面 都 将 被 宣告 无 效 ， 而 由 客户 端 重新 从 服 
务 器 获取 。 

最 后 ， 虽 然 CSS 和 JavaScript 等 基于 文本 的 资源 很 容易 直接 区 入 页 面 ， 也 不 会 带 来 
多 余 的 开销 ， 但 非 文 本 性 资源 则 必须 通过 base64 编码 ， 而 这 会 导致 开销 明显 增 大 : 
编码 后 的 资源 大 小 比 原 大 小 增 大 33% | 

















地 aa 


base64 编码 使 用 64 个 ASCII 符号 和 空白 符 将 任意 字 节 流 编码 为 ASCII 
心 。 字 符 串 。 编 码 过 程 中 ，base64 会 导致 被 编码 的 流 变 成 原来 的 443， 即 增 大 
心 ，339% 的 字 节 开销 。 








实践 中 ， 常 见 的 一 个 经 验 规 则 是 只 考虑 典 入 1~2 KB 以 下 的 资源 ， 因 为 小 于 这 个 标 
准 的 资源 经 常会 导致 比 它 自身 更 高 的 HTTP 开销 。 然 而 ， 如 果 身 入 的 资源 频繁 变更 ， 
又 会 导致 宿主 文档 的 无 效 缓存 率 升 高 。 典 入 资源 也 不 是 完美 的 方法 。 如 果 你 的 应 用 
要 使 用 很 小 的 、 个 别 的 文件 ， 在 考虑 是 否 内 入 时 ， 可 以 参照 如 下 建议 : 


。 如 果 文 件 很 小 ， 而 且 只 有 个 别 页 面 使 用 ， 可 以 考虑 眶 入 ; 

。 如 果 文 件 很 小 ， 但 需要 在 多 个 页 面 中 重用 ， 应 该 考虑 集中 打包 ，; 
。 如 果 小 文件 经 浊 需要 更 新 ， 就 不 要 敌人 了 ， 

。 通过 减少 HTTP cookie 的 大 小 将 协议 开销 最 小 化 。 
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第 12 章 


HTTP 2.0 





HTTP 2.0 可 以 让 我 们 的 应 用 更 快 、 更 简单 、 更 健壮 一 一 这 几 词 凑 到 一 块 是 很 罕见 
的 ! HTTP 2.0 把 很 多 以 前 我 们 针对 HTTP 1.1 想 出 来 的 “ 牌 招 儿 ” 一 笔 匀 销 ， 把 解 
决 那些 问题 的 方案 内 置 在 了 传输 层 中 。 不 仅 如 此 ，HTTP 2.0 还 为 我 们 进一步 优化 应 
用 、 改 进 性 能 ， 提 供 了 全 新 的 机 会 ! 


HTTP 2.0 的 目的 就 是 通过 支持 请 求 与 响应 的 多 路 复 用 来 减少 延迟 ， 通 过 压缩 HITP 
首部 字段 将 协议 开销 降 至 最 低 ， 同 时 增加 对 请 求 优 先 级 和 服务 器 端 推送 的 支持 。 为 
达成 这 些 目标 ，HTTP 2.0 还 会 给 我 们 带 来 大 量 其 他 协议 层面 的 辅助 实现 ， 比 如 新 的 
流量 控制 、 错 误 处 理 和 更 新 机 制 。 上 述 几 种 机 制 虽然 不 是 全 部 ， 但 却 是 最 重要 的 ， 
所 有 Web 开发 者 都 应 该 理解 并 在 自己 的 应 用 中 利用 它们 。 








HTTP 2.0 不 会 改动 HTTP 的 语义 。HTTP 方法 、 状 态 码 、URI 及 首部 字段 ， 等 等 这 
些 核心 概念 一 如 往常 。 但 是 ，HTTP 2.0 修改 了 格式 化 数据 (分 帧 ) 的 方式 ， 以 及 客 
户 端 与 服务 器 间 传 输 这 些 数 据 的 方式 。 这 两 点 统帅 全 局 ， 通 过 新 的 组 帧 机 制 向 我 们 
的 应 用 隐藏 了 所 有 复杂 性 。 换 句 话说 ， 所 有 原来 的 应 用 都 可 以 不 必修 改 而 在 新 协议 
运行 。 这 当然 是 好 事 。 

可 是 ， 我 们 关心 的 不 止 是 交付 能 用 的 应 用 ， 我 们 目标 是 交付 最 佳 性 能 ! HTTP 2.0 
为 我 们 的 应 用 提供 了 很 多 新 的 优化 机 制 ， 这 些 机 制 是 前 所 未 有 的 ， 而 我 们 的 工作 就 
是 把 它们 都 利用 好 。 下 面 我 们 就 来 详细 介绍 一 下 这 些 机 制 。 
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开发 中 的 标准 

一 人 | HTTP 2.0 还 在 积极 的 开发 过 程 中 ， 其 核心 架构 设计 、 原 理 及 特性 非常 完 
善 ， 但 这 不 代表 具体 的 、 底 层 的 实现 也 同样 如 此 。 所 以 ,我们 的 讨论 将 转 
绕 架 构 及 其 意义 展开 ， 同 时 简要 介绍 一 下 数据 格式 。 这 些 对 理解 新 协议 的 
原理 和 用 途 已 经 够 了 。 

要 了 解 HTTP 2.0 标 准 的 最 新 草案 和 状态 ， 请 访问 IETF 的 跟踪 页 面 : 
http://tools.ietf.org/html/draft-ietf-httpbis-http2。 









































12.1 历史 及 其 与 SPDY 的 泪 





源 


SPDY 是 谷歌 开发 的 一 个 实验 性 协议 ， 于 2009 年 年 中 发 布 ， 其 主要 目标 是 通过 解决 
HTTP 1.1 中 广为人知 的 一 些 性 能 限制 ， 来 减少 网 页 的 加 载 延迟 。 大 致 上 ， 这 个 项 目 


设 定 的 目标 如 下 : 


。 页 面 加 载 时 间 (PLT，Page Load Time) 降低 50%，; 
。 无 需 网 站 作者 修改 任何 内 容 ， 

。 把 部 署 复杂 性 降 至 最 低 ， 无 需 变更 网 络 基础 设施 ; 

。 与 开源 社区 合作 开发 这 个 新 协议 ， 

。 收集 真实 性 能 数据 ， 验 证 这 个 实验 性 协议 是 否 有 效 。 








硅 六 


为 了 达到 降低 50% 页 面 加 载 时 间 的 目标 ，SPDY 引入 了 一 个 新 的 二 进 制 分 
a 








QS 4 ， 帧 数据 层 ， 以 实现 多 向 请 求 和 响应 、 优 先 次 序 、 最 小 化 及 消除 不 必要 的 网 
二 ， 络 延迟 ， 目 的 是 更 有 效 地 利用 底层 TCP 连接 ; 参见 10.3.2 节 “ 延 迟 是 性 能 
瓶颈 ”。 








首次 发 布 后 不 入， 谷歌 的 两 位 软件 工程 师 Mike Belshe 和 Roberto Peon 就 分 享 了 他 
们 对 这 个 新 实验 性 SPDY 协议 的 实现 结果 、 文 档 和 源 代码 : 





目前 为 止 ， 我 们 只 在 实验 室 条 件 下 测试 过 SPDY。 最 初 的 成 果 很 激动 人 心 : 

通过 模拟 的 家 庭 上 网 线路 下 载 了 25 个 最 流行 的 网 站 之 后 ， 我 们 发 现 性 能 的 

改进 特别 明显 ， 页 面 加 载 速度 最 多 快 了 55%。 

一 一 A2x Faster Web Chromium Blog 

几 年 后 的 2012 年 ， 这 个 新 的 实验 性 协议 得 到 了 Chrome、Firefox 和 Opera 的 支持 ， 
很 多 大 型 网 站 (如 谷歌 、Twitter、Facebook) 都 对 兼容 客户 端 提供 SPDY 会 话 。 换 
句 话说 ，SPDY 在 被 行业 采用 并 证 明 能 够 大 幅 提 升 性 能 之 后 ， 已 经 具备 了 成 为 一 个 
标准 的 条 件 。 最 终 ，HTTP-WG (HTTP Working Group) 在 2012 年 初 把 HTTP 2.0 
提 到 了 议事 日 程 ， 吸 取 SPDY 的 经 验 教训 ， 并 在 此 基础 上 制定 官方 标准 。 
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12.2 走 回 HTTP 2.0 


SPDY 是 HTTP 2.0 的 催化 剂 ， 但 SPDY 并 非 HTTP 2.0。2012 年 初 ，W3C 向 社会 

集 HITP 2.0 的 建议 ， in 
基础 。 从 那 时 起 ，SPDY 已 经 经 过 了 很 多 变化 和 改进 ， 而 且 在 HITP 2.0 官方 标准 公 
布 之 前 ， 还 将 有 很 多 变化 和 改进 。 


在 此 ， 有 必要 回顾 一 下 HTTP 2.0 宣言 草稿 ， 
关键 设计 要 求 : 
HTTP/2.0 应 该 满足 如 下 条 件 : 


。 相对 于 使 用 TCP 的 HTTP 1.1， 用 户 在 大 多 数 情况 下 的 感知 延迟 要 有 实质 上 、 
可 度量 的 改进 ; 

。 解决 HTTP 中 的 “ 队 首 阻塞 ”问题 

。 并 行 操作 无 需 与 服务 器 建立 多 个 连接 ， 从 而 改进 TCP 的 利用 率 ， 特 别 是 拥塞 
控制 方面 

。 保持 HTTP 1.1 的 语义 ,利用 现 有 文档 ,包括 (但 不 限于 ) HTTP 方法 .状态 三、 
URI， 以 及 首部 字段 ; 

。 明确 规定 HTTP 2.0 如 何 与 HTTP 1.x 互 操作 ， 特 别 是 在 中 间 介 质 上 ; 

。 明确 指出 所 有 新 的 可 扩展 机 制 以 及 适当 的 扩展 策略 。 


对 现 有 的 HTTP 部 署 一 一 特别 是 Web 浏览 器 (桌面 及 移动 ) 、 非 浏览 器 (“HTTP 
API”)、Web 服务 (各 种 规模 ) ， 以 及 中 间 介 质 (代理 、 公 司 防火 墙 、“ 反 向 ” 
代理 及 CDN) 而 言 ， 最 终 规范 应 该 满足 上 述 这 些 目标 。 类 似 地 ， 当 前 和 未 
来 对 HTTP/1.x 的 语义 扩展 〈 如 首部 、 方 法 、 状 态 码 、 缓 存 指令 ) 也 应 该 得 
到 新 协议 的 支持 。 


因为 这 份 宣言 明确 了 该 协议 的 范围 和 





一 一 HTTPbis WG 宣言 HTTP 2.0 


简 言 之 ，HTTP 2.0 致力 于 突破 上 一 代 标 准 众 所 周知 的 性 能 限制 ， 但 它 也 是 对 之 前 
1.x 标准 的 扩展 ， 而 非 奉 代 。HTTP 的 语义 不 变 ， 提 供 的 功能 不 变 ，HTTP 方法 、 状 
态 码 、 URI 和 首部 字段 ， 等 等 这 些 核心 概念 也 不 变 ; 这 些 方面 的 变化 都 不 在 考虑 之 
列 。 既 然 如 此 ， 那 “2.0” 还 名 副 其 实 吗 ? 

之 所 以 要 递增 一 个 大 版 本 到 2.0， 主 要 是 因为 它 改变 了 客户 端 与 服务 器 之 间 交 换 数 据 
的 方式 。 为 实现 宏伟 的 性 能 改进 目标 ，HTTP 2.0 增加 了 新 的 二 进 制 分 帧 数据 层 ， 而 
这 一 层 并 不 兼容 之 前 的 HTTP 1.x 服务 器 及 客户 端 一 一 是 谓 2.0。 











除非 你 在 实现 Web 服务 器 或 者 定制 客户 端 ， 需要 使 用 原始 的 TCP 套 接 字 ， 

rs 否则 你 很 可 能 注意 不 到 HTTP 2.0 技术 面 的 实际 变化 : 所 有 新 的 、 低 级 分 

笃 ， 帧 机 制 都 是 浏览 器 和 服务 器 为 你 处 理 的。 或 许 唯一 的 区 别 就 是 可 选 的 API 
多 了 一 些 ， 比 如 服务 器 推送 ! 
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最 后 ， 有 必要 了 解 一 下 HTTP 2.0 的 进度 。 开 发 一 个 支撑 所 有 Web 通信 协议 的 升级 
版 可 不 是 件 小 事 ， 需 要 周密 考虑 、 反 复试 验 、 多 方 协调 。 因 此 ， 猜 测 HTTP 2.0 什 
么 时 候 制 定 完成 很 不 靠 谱 ， 我 们 只 能 说 : 到 完成 的 时 候 自 然 就 完成 了 。 话 虽 这 么 说 ， 
但 HTTP-WG 的 进度 并 不 慢 ， 下 面 是 官方 目前 设置 的 里 程 碑 。 


。 2012 年 3 月 : 征集 HTTP 2.0 建议 。 

。 2012 年 9 月 : HTTP 2.0 的 第 一 个 草案 发 布 。 

。 2013 年 7 月 : HTTP 2.0 草案 的 第 一 个 实现 发 布 。 

。 2014 年 4 月 : 工作 组 最 后 征集 关于 HTTP 2.0 的 意见 。 
。 2014 年 11 月: 将 HTTP 2.0 作为 建议 标准 提交 给 IESG。 


2012 年 到 2014 年 之 间 的 主要 工作 集中 在 草案 编辑 和 试验 方面 。 根 据 进展 情况 ， 以 
及 实现 者 和 业界 的 反馈 ， 整 个 进度 可 能 会 相应 调整 。 好 消息 是 ， 截 止 2013 年 初 ， 这 
个 计划 进展 顺利 ! 








HTTP 2.0 与 SPDY 共同 进化 


2012 年 夏天 ，HTTP 工作 组 采用 了 SPDY v2 草案 作为 制定 HTTP 2.0 标准 的 起 点 。 
但 SPDY 的 制定 工作 并 没有 因此 停滞 ， 相 反 它 也 还 在 并 行进 化 : 

。 2012 年 发 布 的 SPDY v3 涵盖 更 新 的 帧 格式 和 对 流量 控制 的 初次 实现 ; 

。 2013~2014 年 即将 发 布 的 SPDY v4 会 再 次 更 新 帧 格式 ， 包 人 金 改 进 的 优先 级 排 

定 机 制 、 流 量 控制 及 服务 器 推送 的 实现 。 

之 所 以 还 要 继续 制定 SPDY， 原 因 很 简单 : 把 它 作 为 HTTP 2.0 新 功能 及 新 建议 的 
实验 场 。 纸 上 谈 兵 未 必 实 际 ， 而 实际 上 可 行 的 办 法 ， 未 必 能 在 撰写 规范 时 想 出 来 。 
SPDY 为 HTTP 2.0 标准 收纳 每 一 项 建议 ,提供 了 事前 的 测试 和 评估 手段 。 


SPDY 和 HTTP 2.0 的 渐进 发 展 和 共同 进化 ， 给 实现 者 带 来 了 很 大 的 工作 量 ， 但 也 
带 来 很 多 好 处 : 规范 和 客户 端 及 服务 器 的 实现 ， 也 能 够 并 行进 化 ， 并 得 到 可 靠 和 
广泛 的 测试 。 事 实 上 ， 等 到 HTTP 2.0 的 状态 变 成 “就 绪 ” 时 ,主流 客户 端 和 服务 
器 都 将 内 置 经 过 了 完备 测试 的 实现 ! 到 那 时 ，SPDY 就 可 以 退役 了 ，HTTP 2.0 将 
粉墨登场 。 











12.3 设计 和 技术 目标 


HTTP 1.x 的 设计 初衷 主要 是 实现 要 简单 ， HTTP 0.9 只 用 一 行 协 议 就 启动 了 万 维 网 ; 
HTTP 1.0 则 是 对 流行 的 0.9 扩展 的 一 个 正式 说 明 ; HTTP 1.1 则 是 IETF 的 一 份 官方 
标准 (参见 第 9 章 )。 因 此 ，HTTP 0.9~1.x 只 描述 了 现实 是 怎么 一 回 事 : HTTP 是 应 
用 最 广泛 、 采 用 最 多 的 一 个 互联 网 应 用 协议 。 
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然而 ， 实 现 简单 是 以 牺牲 应 用 性 能 为 代价 的 ， 而 这 正 是 HTTP 2.0 要 致力 于 解决 的 : 





HTTP/2.0 通过 支持 首部 字段 压缩 和 在 同一 连接 上 发 送 多 个 并 发 消息 ， 让 应 
用 更 有 效 地 利用 网 络 资源 ， 减 少 感知 的 延迟 时 间 。 而 且 ， 它 还 支持 服务 器 到 
客户 端的 主动 推送 机 制 。 

一 一 HTTP/2.0，Draft 4 


HTTP 2.0 当前 还 在 制定 过 程 中 ， 因 此 如 何 编码 每 一 帧 中 的 比特 、 每 个 字段 叫 什么 名 
字 ， 以 及 类 似 的 底层 细 市 都 可 能 会 变化 。 但 是 ， 尽 管 “ 怎 么 ”会 不 断 演进 ， 可 核心 
设计 和 技术 目标 却 是 可 以 讨论 的 。 这 些 内 容 已 经 取得 了 多 方 的 理解 和 共识 。 











12.3.1 ”二进制 分 帧 层 
HTTP 2.0 性 能 增强 的 核心 ， 全 在 于 新 增 的 二 进 制 分 帧 层 (图 12-1)， 它 定义 了 如 何 
封装 HTTP 消息 并 在 客户 端 与 服务 器 之 间 传 输 。 








应 用 层 (HTTP 2.0) 
二 进 制 分 帧 POST /upload HTTP/1.1 
-上 Host: www.example.org 


Content-Type: application/json 
会 话 层 (TLS) (可 选 ) Content-Length: 15 


{"'msg":"hello"} 
传输 层 (TCP) 
HTTP 2.0 


DATA 帧 














12-1， HTTP 2.0 二 进 制 分 帧 层 


这 里 所 谓 的 “ 层 ”， 指 的 是 位 于 套 接 字 接 口 与 应 用 可 见 的 高 层 HTTP API 之 间 的 一 
个 新 机 制 : HTTP 的 语义 ， 包 括 各 种 动词 、 方 法 、 首 部 ， 都 不 受 影响 ， 不 同 的 是 传 
输 期 间 对 它们 的 编码 方式 变 了 。HTTP 1.x 以 换行 符 作 为 纯 文本 的 分 隔 符 ， 而 HTTP 
2.0 将 所 有 传输 的 信息 分 割 为 更 小 的 消息 和 帆 ， 并 对 它们 采用 二 进 制 格式 的 编码 。 














这 样 一 来 ， 客 户 端 和 服务 器 为 了 相互 理解 ， 必 须 都 使 用 新 的 二 进 制 编码 机 制 : HTTP 
1.x 客户 端 无 法 理解 只 支持 HTTP 2.0 的 服务 器 ， 反 之 亦 然 。 不 过 不 要 紧 ， 现 有 的 应 
用 不 必 担 心 这 些 变化 ， 因 为 客户 端 和 服务 器 会 替 它 们 完成 必要 的 分 帧 工作 。 
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二 。 


二 HTTPS 是 二 进 制 分 帧 的 另 一 个 典型 示例 : 所 有 HTTP 消息 都 以 透明 的 方 
式 为 我 们 编码 和 解码 (参见 4.6 节 “TLS 记录 协议 ”) ， 从 而 实现 客户 端 与 
服务 器 安全 通信 ， 但 不 必 对 应 用 进行 任何 修改 。HTTP 2.0 的 工作 原理 差 不 

多 也 是 这 样 。 





12.3.2 流 、 消 息 和 帧 


新 的 二 进 制 分 帧 机 制 改变 了 客户 端 与 服务 器 之 间 交 互 数据 的 方式 (图 12-2) 。 为 了 


说 明 这 个 过 程 ， 我 们 需要 了 解 HTTP 2.0 的 两 个 新 概念 。 


。 流 


已 建立 的 连 车 接 上 的 双向 字 节 流 


。 消息 
与 逻辑 消息 对 应 的 完整 的 一 系列 数据 帧 。 


。 帧 


HTTP 2.0 通信 的 最 小 单位 ， 每 个 帧 包含 帧 首部 ， 至 少 也 会 标识 出 当前 帧 所 属 的 流 。 





连接 


请 求 消息 


一 
二 














图 12-2: HTTP 2.0 流 、 消 息 和 帧 


所 有 HTTP 2.0 通信 都 在 一 个 连接 上 完成 ， 这 个 连接 可 以 承载 任意 数量 的 双向 数据 
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流 。 相 应 地 ， 每 个 数据 流 以 消息 的 形式 发 送 ， 而 消息 由 一 或 多 个 帧 组 成 ,这些 帧 可 

以 乱 序 发 送 ， 然 后 再 根据 每 个 帧 首部 的 流标 识 符 重新 组 装 。 

re HTTP 2.0 的 所 有 帧 都 采用 二 进 制 编码 ， 所 有 首部 数据 都 会 被 压缩 。 因 此 ， 

人 Q 4 、 图 12-2 只 是 说 明了 数据 流 、 消 息 和 帧 之 间 的 关系 ， 而 非 它们 实际 传输 时 的 
个 ”编码 结果 。 要 了 解 实际 编码 结果 ， 请 参考 12.4 节 “ 二 进 制 分 帧 简介 ”。 











这 简 简 单单 的 几 句 话 里 浓缩 了 大 量 的 信息 ， 我 们 再 重申 一 次 。 要 理解 HITP 2.0， 就 
必须 理解 流 、 消 息 和 帧 这 几 个 基本 概念 。 


。 所 有 通信 都 在 一 个 TCP 连接 上 完成 。 

。 流 是 连接 中 的 一 个 虚拟 信道 ， 可 以 承载 双向 的 消息 ， 每 个 流 都 有 一 个 唯一 的 整数 
标识 符 (1、2…N)。 

。 消息 是 指 逻辑 上 的 HTTP 消息 ， 比 如 请 求 、 响 应 等 ， 由 一 或 多 个 帧 组 成 。 

。 帧 是 最 小 的 通信 和 单位 ， 未 裁 着 特定 类 型 的 数据 ， nT 负 集 ， 等 等 。 


简 言 之 ，HTTP 2.0 把 HTTP 协议 通信 的 基本 单位 缩小 为 一 个 一 个 的 帧 ， 这 些 帧 对 应 
着 逻辑 流 中 的 消息 。 相 应 地 ， 很 多 流 可 以 并 行 地 在 同一 个 TCP 连接 上 交换 消息 。 


12.3.3 ”多 向 请 求 与 响应 

在 HTTP 1.x 中 ， 如 果 客 户 端 想 发 送 多 个 并 行 的 请 求 以 及 改进 性 能 ， 那 么 必须 使 用 
多 个 TCP 连接 (参见 11.3 节 “ 使 用 多 个 TCP 连接 ”)。 这 是 HTTP 1.x 交付 模型 的 
直接 结果 ， 该 模型 会 保证 每 个 连接 每 次 只 交付 一 个 响应 (多 个 响应 必须 排队 )。 更 糟 
粹 的 是 ， 这 种 模型 也 会 导致 队 首 阻塞 ， 从 而 造成 底层 TCP 连接 的 效率 低下 。 


HTTP 2.0 中 新 的 二 进 制 分 帧 层 突破 了 这 些 限 制 ， 实 现 了 多 向 请 求 和 响应 : 客户 端 和 
服务 器 可 以 把 HTTP 消息 分 解 为 互 不 依赖 的 帧 (图 12-3) ， 然 后 乱 序 发 送 ， 最 后 再 
在 另 一 端 把 它们 重新 组 合 起 来 。 























HTTP 2.0 连 接 

















图 12-3: HTTP 2.0 在 共享 的 连接 上 同时 发 送 请 求 和 响应 
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图 12-3 中 包含 了 同一 个 连接 上 多 个 传输 中 的 数据 流 : 客户 端正 在 向 服务 器 传输 一 个 
DATA 帧 (stream 5$)， 与 此 同时 ， 服 务 器 正 向 客户 端 乱 序 发 送 stream 1 和 stream 3 
的 一 系列 帧 。 此 时 ， 一 个 连接 上 有 3 个 请 求 / 响应 并 行 交 换 | 


把 HITP 消息 分 解 为 独立 的 帧 ， 交 错 发 送 ， 然 后 在 另 一 端 重新 组 装 是 HTTP 2.0 最 
重要 的 一 项 增强 。 事 实 上 ， 这 个 机 制 会 在 整个 Web 技术 栈 中 引发 一 系列 连锁 反应 ， 
从 而 带 来 巨大 的 性 能 提升 ， 因 为 : 


。 可 以 并 行 交错 地 发 送 请 求 ， 请 求 之 间 互 不 影响 ; 

。 可 以 并 行 交错 地 发 送 响 应 ， 响 应 之 间 互 不 干扰 ; 

。 只 使 用 一 个 连接 即 可 并 行 发 送 多 个 请 求 和 响应 ， 

。 消除 不 必要 的 延迟 ， 从 而 减少 页 面 加 载 的 时 间 ， 

。 不 必 再 为 绕 过 HTTP 1.x 限制 而 多 做 很 多 工作 ， 

。 更 多 优势 。 

总 之 ，HTTP 2.0 的 二 进 制 分 帧 机 制 解决 了 HTTP 1.x 中 存在 的 队 首 阻塞 问题 ， 也 消 
除了 并 行 处 理 和 发 送 请 求 及 响应 时 对 多 个 连接 的 依赖 。 结 有 果 ， 就 是 应 用 速度 更 快 、 
开发 更 简单 、 部 署 成 本 更 低 。 























支持 多 向 请 求 与 响应 ， 可 以 省 掉 针对 HTTP 1.x 限制 所 费 的 那些 脑筋 和 工 

4 4 ， 作 ， 比 如 拼接 文件 、 图 片 精灵 、 域 名 分 区 (参见 13.2 节 “ 针 对 HTTP 1.x 

的 优化 建议 ")。 类 似 地 ， 通 过 减少 TCP 连接 的 数量 ，HTTP 2.0 也 会 减少 
客户 端 和 服务 器 的 CPU 及 内 存 占用 。 


























12.3.4 ”请求 优先 级 
把 HTTP 消息 分 解 为 很 多 独立 的 帧 之 后 ， 就 可 以 通过 优化 这 些 帧 的 交错 和 传输 顺序 ， 
进一步 提升 性 能 。 为 了 做 到 这 一 点 ， 每 个 流 都 可 以 带 有 一 个 31 比特 的 优先 值 : 


。 0 表示 最 高 优先 级 ; 
。 2 -1 表示 最 低 优先 级 。 


有 了 这 个 优先 值 ， 客 户 端 和 服务 器 就 可 以 在 处 理 不 同 的 流 时 采取 不 同 的 策略 ， 以 最 
优 的 方式 发 送 流 、 消 息 和 帧 。 具 体 来 讲 ， 服 务 器 可 以 根据 流 的 优先 级 ， 控 制 资源 分 
配 (CPU、 内 存 、 带 宽 )， 而 在 响应 数据 准备 好 之 后 ， 优 先 将 最 高 优先 级 的 帧 发 送 给 
客户 端 。 
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浏览 器 请 求 优 先 级 与 HTTP 2.0 
浏览 器 在 泻 染 页 面 时 ， 并 非 所 有 资源 都 具有 相同 的 优先 级 : HTML 文档 本 身 对 
构建 DOM 不 可 或 缺 ，CSS 对 构建 CSSOM 不 可 或 缺 ， 而 DOM 和 CSSOM 的 构 
建部 可 能 受到 JavaScript 资源 的 阻塞 (参见 10.1 节 的 附注 栏 “DOM、CSSOM 和 
JavaScript”) ， 其 他 资源 (如 图 片 ) 的 优先 级 都 可 以 降低 。 


为 加 快 页 面 加 载 速度 ， 所 有 现代 浏览 器 都 会 基于 资源 的 类 型 以 及 它 在 页 面 中 的 位 
置 排 定 请 求 的 优先 次 序 ， 其 至 通过 之 前 的 访问 来 学 习 优先 级 模式 比如 ,之 前 
的 洽 染 如 果 被 某 些 资源 阻塞 了 ,那么 同样 的 资源 在 下 一 次 访问 时 可 能 就 会 被 赋予 
更 高 的 优先 级 。 

在 HTTP 1.x 中 ,浏览 器 极 少 能 利用 上 述 优 先 级 信息 ， 因 为 协议 本 身 并 不 支持 多 路 
复 用 ， 也 没有 办 法 向 服务 器 通告 请 求 的 优先 级 。 此 时 ,浏览 器 只 能 依赖 并 行 连接 ， 
且 最 多 只 能 同时 向 一 个 域名 发 送 6 个 请 求 。 于 是 ， 在 等 连接 可 用 期 间 ， 请 求 只 能 
在 客户 说 排队 ， 从 而 增加 了 不 必要 的 网 络 延 迟 。 理 论 上 ，HTTP 管道 可 以 解决 这 
个 问题 ， 只 是 由 于 缺乏 支持 而 无 法 付 诸 实践 。 

HTTP 2.0 一 举 解 决 了 所 有 这 些 低 效 的 问题 ， 浏览 器 可 以 在 发 现 资源 时 立即 分 派 请 
求 ， 指 定 每 个 流 的 优先 级 ， 让 服务 器 决定 最 优 的 响应 次 序 。 这 样 请 求 就 不 必 排 队 
了 ， 了 既 节 省 了 时 间 ， 也 最 大 限度 地 利用 了 每 个 连接 。 














HTTP 2.0 没有 规定 处 理 优 先 级 的 具体 算法 ， 只 是 提供 了 一 种 赋予 数据 优先 级 的 机 
制 ， 而 且 要 求 客户 端 与 服务 器 必须 能 够 交换 这 些 数 据 。 这 样 一 来 ， 优 先 值 作为 提示 
信息 ， 对 应 的 次 序 排 定 策略 可 能 因 客 户 端 或 服务 器 的 实现 而 不 同 : 客户 端 应 该 明确 
指定 优先 值 ， 服 务 器 应 该 根据 该 值 处 理 和 交付 数据 。 


在 这 个 规定 之 下 ， 尽 管 你 可 能 无 法 控制 客户 端 发 送 的 优先 值 ， 但 或 许 你 可 以 控制 服 
务 器 。 因 此 ， 在 选择 HTTP 2.0 服务 器 时 ， 可 以 多 留 点 心 ! 为 说 明 这 一 点 ， 考 虑 下 
面 几 个 问题 。 


。 如 果 服 务 器 对 所 有 优先 值 视 而 不 见 怎么 办 ? 

。 高 优先 值 的 流 一 定 优先 处 理 吗 ? 

。 是 否 存 在 不 同 优先 级 的 流 应 该 交错 的 情况 ? 

如 果 服 务 器 不 理 竖 所 有 优先 值 ， 那 么 可 能 会 导致 应 用 响应 变 慢 : 浏览 器 明明 在 等 关 
键 的 CSS 和 JavaScript， 服 务 器 却 在 发 送 图 片 ， 从 而 造成 泻 染 阻塞 。 不 过 ， 规 定 严 
格 的 优先 级 次 序 也 可 能 带 来 次 优 的 结果 ， 因 为 这 可 能 又 会 引入 队 首 阻 塞 问题 ， 即 某 
个 高 优先 级 的 慢 请 求 会 不 必要 地 阻塞 其 他 资源 的 交付 。 


服务 器 可 以 而 且 应 该 交错 发 送 不 同 优先 级 别 的 帧 。 只 要 可 能 ， 高 优先 级 流 都 应 该 优 
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先 ， 包 括 分 配 处 理 资源 和 客户 端 与 服务 器 间 的 带宽 。 不 过 ， 为 了 最 高 效 地 利用 底层 
连接 ， 不 同 优先 级 的 混合 也 是 必需 的 。 


12.3.5 每 个 来 源 一 个 连接 
有 了 新 的 分 帧 机 制 后 ，HTTP 2.0 不 再 依赖 多 个 TCP 连接 去 实现 多 流 并 行 了 。 现 在 ， 
每 个 数据 流 都 拆 分 成 很 多 帆 ， 而 这 些 帧 可 以 交错 ， 还 可 以 分 别 优 先 级 。 于 是 ， 所 有 
HTTP 2.0 连接 都 是 持久 化 的 ， 而 且 客 户 端 与 服务 器 之 间 也 只 需要 一 个 连接 即 可 。 
实验 表明 ， 客 户 端 使 用 更 少 的 连接 肯定 可 以 降低 延迟 时 间 。HTTP 2.0 发 送 的 
总 分 组 数量 比 HTTP 差不多 要 少 40%。 而 服务 器 处 理 大 量 并 发 连接 的 情况 也 
变 成 了 可 伸缩 性 问题 ， 因 为 HITP 2.0 减轻 了 这 个 负担 。 
一 一 HT.TP/2.0 
Draft 2 
每 个 来 源 一 个 连接 显著 减少 了 相关 的 资源 占用 : 连接 路 径 上 的 套 接 字 管理 工作 量 少 
了 ， 内 存 占用 少 了 ， 连 接 吞 吐 量 大 了 了。 此外， 从 上 到 下 所 有 层面 上 也 都 获得 了 相应 
的 好 处 : 


。 所 有 数据 流 的 优先 次 序 始 终 如 一 ，; 

。 压缩 上 下 文 单一 使 得 压缩 效果 更 好 ， 

。 由 于 TCP 连接 减少 而 使 网 络 拥 塞 状 况 得 以 改观 ， 
。 慢 局 动 时 间 减 少 ， 拥 塞 和 丢 包 恢复 速度 更 快 。 





于 | 
本 大 多 数 HTTP 连接 的 时 间 都 很 短 ， 而 且 是 突 发 性 的 ， 但 TCP 只 在 长 时 间 连 
心 、 接 传输 大 块 数据 时 效率 才 最 高 。HTTP 2.0 通过 让 所 有 数据 流 共 用 同一 个 连 
心 ， 接 ， 可 以 更 有 效 地 使 用 TCP 连接 。 








HTTP 2.0 不 仅 能 够 减少 网 络 延迟 ， 还 有 助 于 提高 吞吐 量 和 降低 运营 成 本 ! 





丢 包 、 高 RTT 连接 和 HTTP 2.0 性 能 


等 一 等 ， 我 听 你 说 了 一 大 堆 每 个 来 源 一 个 TCP 连接 的 好 处 ， 难 道 它 就 一 点 坏处 都 

没有 吗 ? 有， 当然 有 。 

。 虽然 消除 了 HTTP 队 首 阻塞 现象 , 但 TCP 层次 上 仍然 存在 队 首 阻塞 (参见 2.4 
节 “ 队 首 阻 塞 ”) ; 

。 如 果 TCP 窗口 缩放 被 禁用 ， 那 带宽 延迟 积 效 应 可 能 会 限制 连接 的 吞吐 量 ; 

。 丢 包 时 ，TCP 拥塞 窗口 会 缩小 (参见 2.2.3 节 “ 拥 塞 预防 ”)， 
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上 述 每 一 点 都 可 能 对 HTTP 2.0 连接 的 吞吐 量 和 延迟 性 能 造成 不 利 影响 。 然 而 ， 
除了 这 些 局 限 性 之 外 ， 实 验 表 明 一 个 TCP 连接 仍然 是 HTTP 2.0 基础 上 的 最 佳 
部 署 策略 : 

目前 为 止 的 测试 表明 ， 压 缩 和 优先 级 排 定 带 来 的 性 能 提升 ， 已 经 超过 了 

队 首 阻塞 (特别 是 丢 包 情况 下 ) 造成 的 负面 效果 。 


一 一 HITP/2.0 
Draft 2 


与 所 有 性 能 优化 过 程 一 样 ， 去 掉 一 个 性 能 瓶颈 ， 又 会 带 来 新 的 瓶颈 。 对 HTTP 
2.0 而 言 ，TCP 很 可 能 就 是 下 一 个 性 能 瓶颈 。 这 也 是 为 什么 服务 器 端 TCP 配置 对 
HTTP 2.0 至 关 重 要 的 一 个 原因 。 

目前 ， 针 对 TCP 性 能 优化 的 研究 还 在 进行 中 : TCP 快速 打开 、 比 例 降 速 、 增 大 的 
初始 拥塞 窗口 ， 等 等 不 一 而 足 。 总 之 ， 一 定 要 知道 HTTP 2.0 与 之 前 的 版 本 一 样 ， 
并 不 强制 使 用 TCP。UDP 等 其 他 传输 协议 也 并 非 不 可 以 。 











12.3.6 流量 控制 

在 同一 个 TCP 连接 上 传输 多 个 数据 流 ， 就 意味 着 要 共享 带宽 。 标 定数 据 流 的 优先 级 
有 助 于 按 序 交 付 ， 但 只 有 优先 级 还 不 足以 确定 多 个 数据 流 或 多 个 连接 间 的 资源 分 配 。 
为 解决 这 个 问题 ，HTTP 2.0 为 数据 流 和 连接 的 流量 控制 提供 了 一 个 简单 的 机 制 |: 














。 流量 控制 基于 每 一 跳 进 行 ， 而 非 端 到 端的 控制 ， 

。 流量 控制 基于 窗口 更 新 帧 进行 ， 即 接收 方 广播 自己 准备 接收 某 个 数据 流 的 多 少 字 
节 ， 以 及 对 整个 连接 要 接收 多 少 字 节 ， 

。 流量 控制 窗口 大 小 通过 WwINDOW_UPDATE 帧 更 新 ， 这 个 字段 指定 了 流 ID 和 窗口 大 小 
递增 值 ， 

。 流量 控制 有 方向 性 ， 即 接收 方 可 能 根据 自己 的 情况 为 每 个 流 乃 至 整个 连接 设置 任 
意 窗口 大 小 ; 

。 流量 控制 可 以 由 接收 方 禁 用 ， 包 括 针 对 个 别 的 流 和 针对 整个 连接 。 








， 双 向 的 流量 控制 窗口 大 小 。 除 此 之 外 ， 任 何 一 端 都 可 以 选择 禁用 个 别 流 或 
:整个 连接 的 流量 控制 。 





2 HTTP 2.0 连接 建立 之 后 ， 客 户 端 与 服务 器 交换 SETTINGS 帧 ， 目 的 是 设置 
pA 
4 








上 面 这 个 列表 是 不 是 让 你 想起 了 TCP 流量 控制 ? 应 该 是 ， 这 两 个 机 制 实际 上 是 一 样 
的 ， 参 见 2.2.1 节 “ 流 量 控制 "。 然 而 ， 由 于 TCP 流量 控制 不 能 对 同一 条 HTTP 2.0 
连接 内 的 多 个 流 实施 差异 化 策略 ， 因 此 光 有 它 自 己 是 不 够 的 。 这 正 是 HTTP 2.0 流 
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量 控制 机 制 出 台 的 原因 。 


HTTP 2.0 标准 没有 规定 任何 特定 的 算法 、 值 ， 或 者 什么 时 候 发 送 WINDOW_UPDATE 帧 。 
因此 ， 实 现 可 以 选择 自己 的 算法 以 匹配 自己 的 应 用 场景 ， 从 而 求 得 最 佳 性 能 。 


优先 级 可 以 决定 交付 次 序 ， 而 流量 控制 则 可 以 控制 HTTP 2.0 连接 中 每 个 流 
心 、 占 用 的 资源 :接收 方 可 以 针对 特定 的 流 广播 较 低 的 窗口 大 小 ， 以 限制 它 的 
心 ， 传 输 速度 。 





12.3.7 服务 器 推送 

HTTP 2.0 新 增 的 一 个 强大 的 新 功能 ， 就 是 服务 器 可 以 对 一 个 客户 端 请 求 发 送 多 个 
响应 。 换 名 话说 ， 除 了 对 最 初 请 求 的 响应 外 ， 服 务 器 还 可 以 额外 向 客户 端 推送 资源 
(图 12-4) ， 而 无 需 客户 端 明确 地 请 求 。 








HTTP 2.0 连 接 


四 -| 





stream 1: /page.htm] (客户 端 请 求 ) 
Stream 2: /script.js (推送 要 约 ) 
Stream 4: /style.css (推送 要 约 ) 














图 12-4: 服务 器 发 起 推送 资源 的 新 流 (要 约 ) 

已 一 | 建立 HTTP 2.0 连接 后 ， 客 户 端 与 服务 器 交换 SETTINGS 帧 ， 借 此 可 以 限定 

人 4 双向 并 发 的 流 的 最 大 数量 。 因 此 ， 客 户 端 可 以 限定 推送 流 的 数量 ， 或 者 通 
必 ， 过 把 这 个 值 设置 为 0 而 完全 禁用 服务 器 推送 。 











为 什么 需要 这 样 一 个 机 制 呢 ?通常 的 Web 应 用 都 由 几 十 个 资源 组 成 ， 客 户 端 需要 分 
析 服 务 器 提供 的 文档 才能 逐个 找到 它们 。 那 为 什么 不 让 服务 器 提前 就 把 这 些 资源 推 
送 给 客户 端 ， 从 而 减少 额外 的 时 间 延 迟 呢 ? 服务 器 已 经 知道 客户 端 下 一 步 要 请 求 什 
么 资源 了 ， 这 时 候 服 务 器 推送 即 可 派 上 用 场 。 事 实 上 ， 如 果 你 在 网 页 里 嵌入 过 CSS、 
JavaScript， 或 者 通过 数据 URI 杠 入 过 其 他 资源 (参见 11.7 节 “ 骨 入 资源 ”)， 那 你 
就 已 经 亲身 体验 过 服务 器 推送 了 。 
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把 资源 直接 插入 到 文档 中 ， 就 是 把 资源 直接 推送 给 客户 端 ， 而 无 需 客户 端 请 求 。 在 
HTTP 2.0 中 ， 唯 一 的 不 同 就 是 可 以 把 这 个 过 程 从 应 用 中 拿 出 来 ， 放 到 HTTP 协议 本 
身 来 实现 ， 而 且 还 带 来 了 如 下 好 处 : 


。 客户 端 可 以 缓存 推送 过 来 的 资源 ; 
。 客户 端 可 以 拒绝 推送 过 来 的 资源 ; 
。 推送 资源 可 以 由 不 同 的 页 面 共享 ， 
。 服务 器 可 以 按照 优先 级 推送 资源 。 





所 有 推送 的 资源 都 遵守 同 产 策略 。 换 名 话说， 服务 器 不 能 随便 将 第 三 方 资 
人 心 4 ， 源 推送 给 客户 端 ， 而 必须 是 经 过 双方 确认 才 行 。 


, 
昌 
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有 了 服务 器 推送 后 ，HTTP 1.x 时 代 的 大 多 数 插入 或 戏 入 资源 的 做 法 基本 上 也 就 过 时 
了 。 唯 一 有 必要 直接 在 网 页 中 插入 资源 的 情况 ， 就 是 该 资源 只 供 那 一 个 网 页 使 用 ， 
而 且 编 码 代 价 不 大 ， 此 处 仍然 可 以 参考 11.7 节 “ 扔 入 资源 ”。 除 此 之 外 ， 所 有 应 用 
都 应 该 使 用 HTTP 2.0 服务 器 推送 。 

















PUSH_PROMISE 


所 有 服务 器 推送 流 都 由 PUSH_PROMISE 发 端 ， 它 是 除了 对 原始 请 求 的 响应 之 外 ， 服 
务 器 向 客户 珊 发 出 的 有 意 推 送 所 述 资 源 的 信号 。PUSH_PROMISE 帧 中 只 包含 要 约 
(promise) 资源 的 HTTP 首部 。 


客户 端 接收 到 PUSH_PROMISE 帧 之 后 ， 可 以 视 自身 需求 选择 拒绝 这 个 流 (比如 ， 已 
经 绥 存 了 相应 资源 )， 而 这 是 对 HTTP 1.x 的 一 个 重要 改进 。 衣 入 资源 作为 针对 
HTTP 1.x 的 一 种 流行 “优化 技巧 ”， 实 际 上 无 异 于 “强制 推送 ”: 客户 端 无 法 取消 
这 种 “推送 ”， 而 且 也 不 能 个 别 地 缓存 上 说 入 的 资源 。 

最 后 再 说 一 说 服务 器 推送 的 几 点 限制 。 首 先 ， 服 务 器 必须 遵循 请 求 - 响应 的 循环 ， 
只 能 借 着 对 请 求 的 响应 推送 资源 。 也 就 是 说 ， 服 务 器 不 能 随意 发 起 推送 流 。 其 次 ， 
PUSH_PROMISE 帧 必须 在 返回 响应 之 前 发 送 ， 以 免 客户 痛 出 现 竟 态 条 件 。 否 则 ， 就 
可 能 出 现 比如 这 种 情况 : 客户 端 请 求 的 恰好 是 服务 器 打算 推送 的 资源 。 











实现 HTTP 2.0 服 务 器 推送 

服务 器 推送 为 优化 应 用 的 资源 交付 提供 了 很 多 可 能 。 然 而 ， 服 务 器 到 底 如 何 确定 哪 
些 资 源 可 以 或 应 该 推送 呢 ? 与 确定 优先 级 类 似 ，HTTP 2.0 标准 也 没有 就 此 规定 某 种 
算法 ， 所 以 实现 者 就 拥有 了 解释 权 。 自 然 地 ， 也 就 有 可 能 出 现 多 种 策略 ， 每 种 策略 
可 能 会 考虑 一 种 应 用 或 服务 器 使 用 场景 。 
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。 应 用 可 以 在 自身 的 代码 中 明确 发 起 服务 器 推送 。 这 种 情况 要 求 与 HTTP 2.0 紧密 
耦合 ， 但 开发 人 员 有 控制 权 。 

。 应 用 可 以 通过 额外 的 HTTP 首部 向 服务 器 发 送信 号 ， 列 出 它 希 望 推送 的 资源 。 这 
样 可 以 将 应 用 与 HTTP 服务 器 API 分 离 。 比 如 Apache 的 mod_spdy 能 够 识别 
X-Associated-Content 首部 ， 这 个 首部 中 列 出 了 希望 服务 器 推送 的 资源 。 

。 服务 器 可 以 不 依赖 应 用 而 自动 学 习 相 关 资 源 。 服 务 器 可 以 解析 文档 ， 推 断 出 要 
推送 的 资源 ， 或 者 可 以 分 析 流 量 ， 然 后 作出 适当 的 决定 。 比 如 服务 器 可 以 根据 
Referer 首部 收集 依赖 数据 ， 然 后 自动 向 客户 端 推送 关键 资源 。 


当然 ， 以 上 只 是 各 种 可 能 策略 中 的 几 个 ， 但 由 此 也 可 以 知道 可 能 性 是 很 多 的 : 可 能 
是 手工 调用 低级 API， 也 可 能 是 一 种 全 自动 的 实现 。 类 似 地 ， 服 务 器 应 不 应 该 重复 
推送 相同 的 资源 ， 还 是 应 该 实现 一 个 更 智能 的 策略 ?服务 器 可 以 根据 自身 的 模型 、 
客户 端 cookie 或 其 他 机 制 ， 智 能 推断 出 客户 端 缓 在 中 有 什么 资源 ， 然 后 再 作出 推送 
决定 。 简 言 之 ， 服 务 器 推送 领域 将 爆 出 各 种 创新 。 

最 后 还 有 一 点 ， 就 是 推送 的 资源 将 直接 进入 客户 端 缓 存 ， 就 像 客 户 端 请 求 了 似 的 。 
不 存在 客户 端 API 或 JavaScript 回调 方法 等 通知 机 制 ， 可 以 用 于 确定 资源 何 时 到 达 。 
整个 过 程 对 运行 在 浏览 器 中 的 Web 应 用 来 说 好 像 根 本 不 存在 。 



































12.3.8 首部 压缩 

HTTP 的 每 一 次 通信 都 会 携带 一 组 首部 ， 用 于 描述 传输 的 资源 及 其 属性 。 在 HTTP 
1.x 中 ， 这 些 元 数据 都 是 以 纯 文 本 形式 发 送 的 ， 通 常会 给 每 个 请 求 增加 500~800 字 
节 的 负荷 。 如 果 算 上 HTTP cookie， 增 加 的 负荷 通常 会 达到 上 千 字 节 (参见 11.5 市 
“度量 和 控制 协议 开销 ”)。 为 减少 这 些 开销 并 提升 性 能 ，HTTP 2.0 会 压缩 首部 元 数 
据 : 


。 HTTP 2.0 在 客户 端 和 服务 器 端 使 用 “首部 表 ” 来 跟踪 和 存储 之 前 发 送 的 键 一 值 对 ， 
对 于 相同 的 数据 ， 不 再 通过 每 次 请 求 和 响应 发 送 ， 

。 首部 表 在 HTTP 2.0 的 连接 存续 期 内 始终 存在 ,由 客户 端 和 服务 器 共同 渐进 地 更 新 ; 

。 每 个 新 的 首部 键 一 值 对 要 么 被 追加 到 当前 表 的 末尾 ， 要 么 禁 换 表 中 之 前 的 值 。 


于 是 ，HTTP 2.0 连接 的 两 端 都 知道 已 经 发 送 了 哪些 首部 ， 这 些 首部 的 值 是 什么 ， 从 
而 可 以 针对 之 前 的 数据 只 编码 发 送 差异 数据 (图 12-5)。 
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请 求 #1 请 求 妃 


已 有 


HEADERS 帧 (stream 1) HEADERS 帆 (stream 3 ) 














图 12-5: HTTP 2.0 首部 的 差异 化 编码 
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2 请 求 与 响应 首部 的 定义 在 HTTP 2.0 中 基本 没有 改变 ， 只 是 所 有 首部 键 必须 

心 。 全 部 小 写 ， 而 且 请 求 行 要 独立 为 :method、:scheme、:host 和 :path 这 些 
0 








… 键 一 值 对 。 

在 前 面 的 例子 中 ， 第 二 个 请 求 只 需要 发 送 变 化 了 的 路 径 首 部 (:path)， 其 他 首部 没有 变 
化 ， 不 用 再 发 送 了 。 这 样 就 可 以 避免 传输 元 余 的 首部 ， 从 而 显著 减少 每 个 请 求 的 开销 。 
通信 期 间 几 乎 不 会 改变 的 通用 键 一 值 对 (用户 代理 、 可 接受 的 媒体 类 型 ， 等 等 ) 只 
需 发 送 一 次 。 事 实 上 ， 如 果 请 求 中 不 包含 首部 (例如 对 同一 资源 的 轮 询 请 求 )， 那 么 
首部 开销 就 是 零 字 节 。 此 时 所 有 首部 都 自动 使 用 之 前 请 求 发 送 的 首部 ! 








SPDY、CRIME 和 HTTP 2.0 压缩 


SPDY 的 早期 版 本 使 用 zlib 和 自 定 义 的 字典 压缩 所 有 HTTP 首部 ， 可 以 减少 
85%~88% 的 首部 开销 ， 从 而 显著 减少 加 载 页 面 的 时 间 : 
在 低速 DSL 连接 中 ， 上 传 速度 只 有 375 KbiVs， 仅 压缩 请 求 首部 ， 即 可 
显著 减少 某 些 (需要 发 送 大 量 资源 请 求 的 ) 站 点 的 页 面 加 载 时 间 。 我 们 
发 现 压 缩 首 部 可 以 节省 45~1142 ms 的 页 面 加 载 时 间 。 
一 一 SPDY 和 白皮书，chromium.org 














然而 ，2012 年 夏天 ， 出 现 了 针对 TLS 和 SPDY 压缩 算法 的 “CRIME” 安 全 攻击 ， 
它 可 以 利用 首部 压缩 拦截 会 话 。 于 是 ，zlib 压缩 算法 被 撤销 ， 取 而 代 之 的 是 前 面 
介绍 的 新 索引 表 工 法。 索引 表 算 法 没有 类 似 的 安全 问题 ， 但 可 以 实现 相差 无 几 的 
性 能 提升 。 

要 全 面 了 解 HTTP 2.0 压缩 算法 ， 请 看 这 里 : http://tools.ietf.org/html/draft-ietf-httpbis- 
header-compression 。 








12.3.9 有 效 的 HTTP 2.0 升 级 与 发 现 
向 HTTP 2.0 的 迁移 不 可 能 一 跃 而 就 。 数 百 万 台 服 务 器 必须 升级 才能 使 用 新 的 二 进 
制 分 帧 ， 还 有 数 十 亿 客 户 端 必 须 更 新 浏览 器 和 网 络 库 。 


好 消息 是 ， 大 多 数 现代 浏览 器 都 内 置 有 高 效 的 后 台 升 级 机 制 ， 因 而 对 相当 大 一 部 分 
既 有 用 户 来 说 ， 这 些 浏 览 器 能 很 快 支持 HTTP 2.0， 又 不 会 带 来 太 多 干扰 。 尽 管 如 
此 ， 还 是 有 一 部 分 用 户 只 能 使 用 旧版 本 的 浏览 器 ， 而 服务 器 和 中 间 设 备 也 必须 升级 
支持 HTTP 2.0， 这 需要 一 个 比较 长 的 时 期 ， 而 且 是 一 个 费力 、 费 钱 的 过 程 。 

HTTP 1.x 至 少 还 会 存在 十 年 以 上 ， 大 多 数 服 务 器 和 客户 端 在 此 期 间 必须 同时 支持 
1.x 和 2.0 标 准 。 于 是 ， 支 持 HTTP 2.0 的 客户 端 在 发 起 新 请 求 之 前 ， 必 须 能 发 现 服 
务 器 及 所 有 中 间 设 备 是 否 支持 HTTP 2.0 协议 。 有 三 种 可 能 的 情况 : 








。 通过 TLS 和 ALPN 发 起 新 的 HTTPS 连接 ， 
。 根据 之 前 的 信息 发 起 新 的 HTTP 连接 ， 
。 没有 之 前 的 信息 而 发 起 新 的 HTTP 连接 。 


HTTPS 协商 过 程 中 有 一 个 环节 会 使 用 ALPN (Application Layer Protocol Negotiation ) 
发 现 和 协商 HTTP 2.0 的 支持 情况 [参见 4.2.1 节 “ 应 用 层 协 议 协 商 (ALPN)”]。 减 
少 网 络 延迟 是 HTTP 2.0 的 关键 条 件 ， 因 此 在 建立 HTTPS 连接 时 一 定 会 用 到 ALPN 
协商 。 

通过 常规 非 加 密 信道 建立 HITP 2.0 连接 需要 多 做 一 点 工作 。 因 为 HTTP 1.0 和 
HTTP 2.0 都 使 用 同一 个 端口 (80)， 又 没有 服务 器 是 否 支持 HTTP 2.0 的 其 他 任何 信 
息 ， 此 时 客户 端 只 能 使 用 HTTP Upgrade 机 制 通过 协调 确定 适当 的 协议 : 




















GET /page HTTP/1.1 

Host: server.example.com 

Connection: Upgrade, HTTP2-Settings 
Upgrade: HTTP/2.0 © 

HTTP2-Settings: (SETTINGS payLoad) © 
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HTTP/1.1 200 OK © 
Content-Length: 243 
Content-type: text/htmL 


(... HTTP 1.1 response ...) 
(or) 


HTTP/1.1 101 Switching Protocols @ 
Connection: Upgrade 
Upgrade: HTTP/2.0 


(... HTTP 2.0 response ...) 


@ 发 起 带 有 HTTP 2.0 Upgrade 首部 的 HTTP 1.1 请 求 
@ HTTP/2.0 SETTINGS 净 答 的 Base64 URL 编码 

@ 服务 器 拒绝 升级 ， 通 过 HTTP 1.1 返回 响应 

@ 服务 器 接受 HITP 2.0 升级 ， 切 换 到 新 分 帧 


使 用 这 种 Upgrade 流 ， 如 果 服 务 器 不 支持 HTTP 2.0， 就 立即 返回 HTTP 1.1 响应 。 
否则 ， 服 务 器 就 会 以 HTTP 1.1 格式 返回 101 Switching Protocols 响应 ， 然 后 立即 
切换 到 HTTP 2.0 并 使 用 新 的 二 进 制 分 帧 协议 返回 响应 。 无 论 哪 种 情况 ， 都 不 需要 
额外 往返 


为 确定 服务 器 和 客户 端 都 有 意 使 用 HTTP 2.0 对 话 ， 双 方 还 必须 发 送 “ 连 接 
心 首部 ”， 也 就 是 一 串 标 准 的 字 节 。 这 种 信息 交换 本 质 上 是 一 种 “尽早 失败 ” 
(fail-fast) 的 机 制 ， 可 以 避免 客户 端 、 服 务 器 ， 以 及 中 间 设 备 偶尔 接受 请 
求 的 升级 却 不 理解 新 协议 。 We 这 种 信息 交换 也 不 会 带 来 额外 的 往返 ， 
只 是 在 连接 开始 时 要 多 传 一 些 字 


























， 如 果 客 户 端 因为 自己 保存 有 或 通过 其 他 手段 (如 DNS 记录 、 手 工 配置 等 ) 获 
: HTTP 2.0 的 支持 信息 ， 它 也 可 以 直接 发 送 HTTP 2.0 分 帧 ， 而 不 必 依 赖 
Upgrade 机 制 。 有 了 这 些 信息 ， 客 户 端 可 以 一 上 来 就 通过 非 加 密 信道 发 送 HTTP 2.0 
分 帧 ， 其 他 就 不 管 了 。 最 坏 的 情况 ， 就 是 无 法 建立 连接 ， 客 户 端 再 回 退 一 步 ， 重 新 
使 用 Upgrade 首部 ， 或 者 切换 到 带 ALPN 协商 的 TLS 信道 。 





部 署 HTTP 2.0 的 同时 部 署 TLS 和 ALPN 
服务 器 之 前 的 HTTP 2.0 支持 信息 并 不 能 保证 下 一 次 就 能 可 靠 地 建立 连接 。 以 这 种 
方式 通信 的 前 提 ， 就 是 各 端 都 必须 支持 HTTP 2.0。 如 果 任何 中 间 设 备 不 支持 ， 连 
接 都 不 会 成 功 。 
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因此 ， 尽 管 HTTP 2.0 并 不 要 求 使 用 TLS， 但 在 实践 中 ， 将 其 部 署 到 现 有 的 大 量 
中 间 设 备 仍 re 策略 (参见 4.1 节 中 的 “Web 代理 、 中 间 设 备 、TLS 与 
新 协议 ”)。 最 好 的 结 就 是 除了 常规 的 Upgrade 工作 流 ， 还 要 在 部 署 HTTP 2.0 
a eh 





12.4 二进制 分 帧 简介 


HTTP 2.0 的 根本 改进 还 是 新 增 的 长 度 前 置 的 二 进 制 分 帧 层 。 与 HTTP 1.x 使 用 换行 
符 分 隔 纯 文本 不 同 ， 二 进 制 分 帧 层 更 加 简洁 ， 通 过 代码 处 理 起 来 更 简单 也 更 有 效 。 


建立 了 HTTP 2.0 连接 后 ， 客 户 端 与 服务 器 会 通过 交换 帧 来 通信 ， 帧 是 基于 这 个 新 
协议 通信 的 最 小 单位 。 所 有 帧 都 共享 一 个 8 字 节 的 首部 (图 12.6) ， 其 中 包含 帧 的 
长 度 、 类 型 、 标 志 ， 还 有 一 个 保留 位 和 一 个 31 位 的 流标 识 符 。 














人 
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El 














图 12-6: 共有 的 8 字 节 帧 首 言 


。 16 位 的 长 度 前 缀 意味 着 一 帧 大 约 可 以 携带 64 KB 数据 ， 不 包括 8 字 节 首部 。 
。 8 位 的 类 型 字段 决定 如 何 解 释 帧 其 余部 分 的 内 容 。 

。 8 位 的 标志 字段 允许 不 同 的 帧 类 型 定义 特定 于 帧 的 消息 标志 。 

。 1 位 的 保留 字段 始终 置 为 0。 

。 31 位 的 流标 识 符 唯一 标识 HTTP 2.0 的 流 。 














在 调试 HTTP 2.0 通信 时 ， 有 人 会 使 用 自己 喜欢 的 十 六 进 制 查看 器 。 其 实 ， 
Wireshark 及 其 他 类 似 的 工具 也 有 相应 的 插件 ， 使 用 很 简单 ， 也 很 人 性 化 。 
%， 比如， 谷歌 Chrome 就 支持 chrome://internaLs#spdy， 通 过 它 可 以 查看 
通信 细节 。 









































知道 了 HTTP 2.0 规定 的 这 个 共享 的 帧 首部 ， 就 可 以 自己 编写 一 个 简单 的 解析 器 
通过 分 析 HTTP 2.0 字 节 流 ， 根 据 每 个 闫 的 前 8 字 节 找到 帧 的 类 型 、 标 志和 长 度 。 
而 且 ， 由 于 每 个 帧 的 长 度 都 是 预先 定义 好 的 ， 解 析 器 可 以 迅速 而 准确 地 跳 到 下 一 帧 
的 开始 ， 这 也 是 相对 于 HTTP 1.x 的 一 个 很 大 的 性 能 提升 。 
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知道 了 帧 类 型 ， 解 析 器 就 知道 该 如 何 解 释 帧 的 其 余 内 容 了 。HTTP 2.0 规定 了 如 下 帧 
类 型 。 


。 DATA: 用 于 传输 HTTP 消息 体 。 

。 HEADERS: 用 于 传输 关于 流 的 额外 的 首部 字段 。 

。 PRIORITY: 用 于 指定 或 重新 指定 引用 资源 的 优先 级 。 

。 RST_STREAM: 用 于 通知 流 的 非 正 常 终止 。 

。 SETTINGS: 用 于 通知 两 端 通信 方式 的 配置 数据 。 

。 PUSH_PROMISE: 用 于 发 出 创建 流 和 服务 器 引用 资源 的 要 约 。 
。 PING: 用 于 计算 往返 时 间 ， 执 行 “活性 ”检查 。 

。 GOAWAY: 用 于 通知 对 端 停止 在 当前 连接 中 创建 流 。 

。 WINDOW_UPDATE: 用 于 针对 个 别 流 或 个 别 连接 实现 流量 控制 。 
。 CONTINUATION: 用 于 继续 一 系列 首部 块 片 段 。 























Fe 

oa 服务 器 可 以 利用 GOAWAY 类 型 的 帧 告诉 客户 端 要 人 处理 的 最 后 一 个 流 的 ID， 

心 ， 从 而 消除 一 些 请 求 竞争 ， 而 且 浏 览 器 也 可 以 据 此 智能 地 重 试 或 取消 “ 蕊 着 
必 ， 的 ”请 求 。 这 也 是 保证 复 用 连接 安全 的 一 个 重要 和 必要 的 功能 ! 














前 述 各 种 类 型 帧 的 具体 实现 在 很 大 程度 上 取决 于 服务 器 和 客户 端 开 发 商 ， 他 们 需要 
考虑 流量 控制 、 错 误 处 理 、 连 接 终 止 等 细 闻 。 好 在 ， 所 有 这 些 内 容 在 官方 标准 中 都 
有 论述 。 好 奇 的 话 ， 可 以 查阅 一 下 最 新 的 草案 。 

既然 有 了 这 个 分 帧 层 ， 即 使 它 对 我 们 的 应 用 不 可 见 ， 我 们 也 应 该 更 进一步 ， 分 析 一 
下 两 种 最 常见 的 工作 流 : 发 起 新 流 和 交换 应 用 数据 。 只 有 明白 了 一 个 请 求 或 响应 如 
何 转换 成 一 个 一 个 的 帧 ， 才 能 理解 HTTP 2.0 对 性 能 的 提升 来 自 哪里 。 











固定 长 度 与 可 变 长 度 字段 
HTTP 2.0 只 使 用 固定 长 度 字 段 ，HTTP 2.0 帧 占用 带宽 很 少 ( 帧 首部 是 8 字 节 )。 
采用 可 变 长 度 编码 的 确 可 以 节省 一 点 带宽 和 时 延 ， 但 却 无 法 抵偿 由 此 带 来 的 分 析 
复杂 性 。 
即使 可 变 长 度 编码 能 减少 50% 的 带宽 占用 ， 那 么 在 1 Mbit/s 的 连接 上 传输 1400 字 
节 的 分 组 ， 也 只 能 节省 4 字 节 (0.3%) 和 每 帧 不 到 100 纳 秒 的 延迟 时 间 。 











12.4.1 发 起 新 流 
在 发 送 应 用 数据 之 前 ， 必 须 创 建 一 个 新 流 并 随 之 发 送 相应 的 元 数据 ， 比 如 流 优先 级 、 
HTTP 首部 等 。HTTP 2.0 协议 规定 客户 端 和 服务 器 都 可 以 发 起 新 流 ， 因 此 有 两 种 可 能 : 
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。 客户 端 通过 发 送 HEADERS 帧 来 发 起 新 流 (图 12-7) ， 这 个 帧 里 包含 带 有 新 流 ID 的 
公用 首部 、 可 选 的 31 位 优先 值 ， 以 及 一 组 HTTP 键 一 值 对 首部 ， 

。 服务 器 通过 发 送 PUSH_PROMISE 帧 来 发 起 推送 流 ， 这 个 帧 与 HEADERS 帧 等 效 ， 但 它 
包含 “要 约 流 ID”， 没 有 优先 值 。 
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12-7: 带 优先 值 的 HEADERS 帧 


这 两 种 帧 的 类 型 字段 都 只 用 于 沟通 新 流 的 元 数据 ， 净 荷 会 在 DATA 帧 中 单独 发 送 。 同 
人 由 于 两 端 都 可 以 发 起 新 流 ， 流 计数 器 偏 置 ， 客户 端 发 起 的 流 具 有 偶数 ID ， 服务 

器 发 起 的 流 具 有 奇数 ID。 这 样 ， 两 端的 流 ID 不 会 冲突 ， 而 且 各 自持 有 一 个 简单 的 
计数 器 ， 每 次 发 起 新 流 时 递增 ID 即 可 。 


























ya 

~ 由 于 流 的 元 数据 与 应 用 数据 是 单独 发 送 的 ， 因 此 客户 端 和 服务 器 可 以 分 别 
《SY 4 、 给 它们 设 定 不 同 的 优先 级 。 比 如 , “控制 流量 ”的 流 优先 级 可 以 高 一 些 ， 但 
只 将 其 应 用 给 DATA 帧 。 


























12.4.2 ”发 送 应 用 数据 
创建 新 流 并 发 送 HTTP 首部 之 后 ， 接 下 来 就 是 利用 DATA 帧 (图 12-8) 发 送 应 用 数 
据 。 应 用 数据 可 以 分 为 多 个 DATA 帆 ， 最 后 一 帧 要 翻转 帧 首部 的 END_STREAM 字段 。 








ET 
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12-8: DATA 帧 


数据 净 茶 不 会 被 另行 编码 或 压缩 。 编 码 方式 取决 于 应 用 或 服务 器 ， 纯 文本 、gzip 压 
缩 、 图 片 或 视频 压缩 格式 都 可 以 。 既 然 如 此 ， 关 于 DATA 帧 再 也 没有 什么 新 东西 好 说 
了 ! 整个 帧 由 公用 的 8 字 市 首部 ， 后 跟 HTTP 净 淆 组 成 。 
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，(65 535) 字 节 。 可 是 ， 为 减少 队 首 阻塞 ，HTTP 2.0 标准 要 求 DATA 帧 不 能 


增 、 
1 从 技术 上 说 ，DATA 帧 的 长 度 字段 决定 了 每 帧 的 数据 净 荷 最 多 可 达 2 -1 
AY 
te 
心 ' 超过 21 (16 383) 字 节 。 长 度 超过 这 个 阀 值 的 数据 ， 就 得 分 帧 发 送 。 





12.4.3 HTTP 2.0 帧 数据 流 分 析 
了 解 了 不 同 帧 的 基础 知识 ， 下 面 我 们 再 看 一 看 12.3.3 节 “ 多 向 请 求 与 响应 ”中 的 那 
张 图 (图 12-9), 分 析 一 下 数据 流 。 











HTTP 2.0 连 接 











12-9: HTTP 2.0 在 共享 的 连接 上 同时 发 送 请 求 和 响应 


有 3 个 活动 的 流 : stream 1、stream 3 和 stream 5。 

3 个 流 的 ID 都 是 奇数 ， 说 明 都 是 客户 端 发 起 的 。 

这 里 没有 服务 器 发 起 的 流 。 

服务 器 发 送 的 stream 1 包含 多 个 DATA 帧 ， 这 是 对 客户 端 之 前 请 求 的 响应 数据 。 
这 也 说 明 在 此 之 前 已 经 发 送 过 HEADERS 帧 了 。 

服务 器 在 交错 发 送 stream 1 的 DATA 帧 和 stream 3 的 HEADERS 帧 ， 这 就 是 响应 的 多 
路 复 用 ! 

客户 端正 在 发 送 stream 5 的 DATA 帧 ， 表 明 HEADERS 帧 之 前 已 经 发 送 过 了 。 


简 言 之 ， 图 12-9 中 连接 正在 并 行 传送 3 个 数据 流 ， 每 个 流 都 处 于 各 自 处 理 周期 的 不 
同 阶段 。 服 务 器 决定 帧 的 顺序 ， 而 我 们 不 用 关心 每 个 流 的 类 型 或 内 容 。stream 1 携 


1 


中 








带 的 数据 量 可 能 比较 大 ， 也 许 是 视频 ,但 它 不 会 阻塞 共享 连接 中 的 其 他 流 ! 
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优化 应 用 的 交付 





高 性 能 浏览 器 网 络 有 赖 于 大 量 网 络 技 术 (图 13-1) ， 而 我 们 应 用 的 整体 性 能 则 是 所 
有 这 些 组 成 部 分 性 能 表现 之 和 。 











数据 链 路 层 及 物理 层 











图 13-1: 与 优化 应 用 交付 相关 的 所 有 层 


我 们 无 法 控制 客户 端 与 服务 器 之 间 的 网 络 环境 ， 也 不 能 控制 客户 的 硬件 或 者 其 手持 
设备 的 配置 ， 但 除 此 之 外 的 一 切 就 掌握 在 我 们 手 里 了 ， 包 括 服务 器 上 的 TCP 和 TLS 
优化 ， 以 及 针对 不 同 物理 层 特 性 、 不 同 HTTP 协议 版 本 和 通用 最 佳 实践 的 数 十 项 应 


用 优化 。 没 错 ， 要 做 到 滴水 不 漏 绝 非 易 事 ， 但 这 样 做 绝对 值得 ! 好 ， 下 面 我 们 就 来 
作 一 香 综 述 。 
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通信 信道 的 物理 属性 对 所 有 应 用 而 言 都 是 一 项 硬性 限制 : 光速 及 客户 端 与 服务 器 之 
间 的 距离 决定 了 信号 传播 的 延迟 ， 而 媒介 (有 线 或 无 线 ) 决定 了 由 每 个 数据 分 组 带 
来 的 处 理 、 传 输 、 排 队 及 其 他 延迟 。 事 实 上 ， 影 响 绝 大 多 数 Web 应 用 性 能 的 并 非 带 
宽 ， 而 是 延迟 。 网 速 虽然 越 来 越 快 ， 但 不 幸 的 是 ， 延 迟 似乎 并 没有 缩短 : 


。 1.2 市 “延迟 的 构成 ”; 
。 1.7 市 “目标 : 高 带宽 和 低 延 迟 ”， 
。 10.3.2 市 “延迟 是 性 能 瓶颈 ”。 


既然 我 们 不 能 让 信息 跑 得 更 快 ， 那 么 关键 就 在 于 对 传输 层 和 应 用 层 采 取 各 种 可 能 的 
优化 手段 ， 消 除 不 必要 的 往返 、 请 求 ， 把 每 个 分 组 的 传输 距离 缩 到 最 短 一 一 比如 把 
服务 器 放 到 离 客户 更 近 的 地 方 。 


针对 无 线 网 络 物理 层 的 特有 属性 采取 优化 措施 可 以 让 任何 应 用 受益 ， 因 为 无 线 环境 
的 延迟 高 且 带 宽 总 是 那么 贵 。 对 API 而 言 ， 有 线 与 无 线 网 络 之 间 的 差别 特别 明显 ， 
对 此 视而不见 可 不 明智 。 只 要 对 何 时 以 及 如 何 下 载 资 源 、 信 标 进行 简单 的 优化 ， 就 
能 显著 改善 用 户 感觉 到 的 延迟 、 电 凶 使 用 时 间 和 应 用 的 整体 用 户 体验 : 


。 6.4 节 “针对 Wi-Fi 的 优化 建议 ”; 
。 第 8 章 “ 移 动 网 络 的 优化 建议 ”。 


自 物理 层 向 上 ， 接 下 来 就 是 要 保证 任何 一 台 服 务 器 都 要 按照 最 新 的 TCP 和 TLS 最 
佳 实践 进行 配置 。 针 对 底层 协议 的 优化 能 保证 每 个 客户 端 在 与 服务 器 通信 时 ， 都 可 
以 获取 最 佳 性 能 一 一 高 否 吐 量 和 低 延 迟 : 


。 2.5 节 “针对 TCP 的 优化 建议 ”; 
。 4.7 节 “ 针 对 TLS 的 优化 建议 ”。 


最 后 ， 就 是 应 用 层 。 无 论 从 哪个 角度 讲 ，HTTP 都 是 出 奇 成 功 的 一 个 协议 。 毕 竞 ， 
它 是 数 十 亿 客 户 端 与 服务 器 交流 的 “通用 语言 ， 没 有 它 就 没有 现代 Web (万 维 
网 )。 可 是 ，HTTP 也 是 一 个 不 完美 的 协议 ， 这 就 意味 着 我 们 在 架构 自己 的 应 用 时 必 
须 格 外 小 心 : 


。 我 们 必须 想方设法 地 绕 过 HTTP 1.x 的 种 种 限制 ， 
。 我 们 必须 掌握 利用 HTTP 2.0 性 能 增强 的 方法 ; 
。 我 们 必须 在 应 用 经 典 的 性 能 最 佳 实践 时 保持 警惕 。 
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。 拿 业务 目标 与 性 能 指标 进行 比较 ， 采 取 优化 措施 ， 紧 了 松 点 ， 松 了 紧 点 ， 
、 如 此 反复 。 开 发 和 购买 合用 的 度量 工具 及 选择 恰当 的 度量 手段 具有 最 高 优 
先 级 ;参见 10.4 节 “ 人 造 和 真实 用 户 性 能 度量 "。 


yy 二 
1 说 到 底 ， 成 功 的 、 可 持续 的 Web 性 能 优化 策略 其 实 很 简单 : 先 度 量 ， 然 后 
CA 
es 
4 











13.1 经典 的 性 能 优化 最 佳 实 践 

无 论 什 么 网 络 ， 也 不 管 所 用 网 络 协议 是 什么 版 本 ， 所 有 应 用 都 应 该 致力 于 消除 或 减 
少 不 必 要 的 网 络 延迟 ， 将 需要 传输 的 数据 压缩 至 最 少 。 这 两 条 标准 是 经 典 的 性 能 优 
化 最 佳 实践 ， 是 其 他 数 十 条 性 能 准则 的 出 发 点 。 











减少 DNS 查找 
每 一 次 主机 名 解析 都 需要 一 次 网 络 往返 ， 从 而 增加 请 求 的 延迟 时 间 ， 同 时 还 会 阻 
塞 后 续 请 求 。 
重用 TCP 连 接 
尽 可 能 使 用 持久 连接 ， 以 消除 TCP 握手 和 慢 启 动 延 迟 ， 参见 2.2.2 节 “ 慢 启动 ”。 


减少 HTTP 重 定向 
HTTP 重 定向 极 费 时 间 ， 特 别 是 不 同 域名 之 间 的 重 定向 ， 更 加 费时 ， 这 里 面 既 有 
额外 的 DNS 查询 、TCP 握手， 还 有 其 他 延迟 。 最 佳 的 重 定向 次 数 为 零 。 





使 用 CDN (内 容 分 发 网 络 ) 
把 数据 放 到 离 用 户 地 理 位 置 更 近 的 地 方 ， 可 以 显著 减少 每 次 TCP 连接 的 网 络 延 
迟 ， 增 大 吞吐 量 。 这 一 条 既 适 用 于 静态 内 容 ， 也 适用 于 动态 内 容 ， 参 见 4.7.2 市 
中 的 “不 缓存 的 原始 获取 ”。 


去 掉 不 必要 的 资源 
任何 请 求 都 不 如 没有 请 求 快 。 


说 到 这 ， 所 有 建议 都 无 需 解释 。 延 迟 是 瓶 虎 ， 最 快 的 速度 莫 过 于 什么 也 不 传输 。 然 
而 ，HTTP 也 提供 了 很 多 额外 的 机 制 ， 比 如 缓存 和 压缩 ， 还 有 与 其 版 本 对 应 的 一 些 
性 能 技巧 。 





在 客户 端 缓存 资源 
应 该 缓存 应 用 资源 ， 从 而 避免 每 次 请 求 都 发 送 相同 的 内 容 。 
传输 压缩 过 的 内 容 


传输 前 应 该 压缩 应 用 资源 ， 把 要 传输 的 字 市 减 至 最 少 :， 确保 对 每 种 要 传输 的 资源 
采用 最 好 的 压缩 手段 。 
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。 消除 不 必要 的 请 求 开销 
减少 请 求 的 HTTP 首部 数据 (比如 HITP cookie)， 节 省 的 时 间 相 当 于 几 次 往返 
的 延迟 时 间 。 


。 并 行 处 理 请 求 和 响应 


请 求 和 响应 的 排队 都 会 导致 延迟 ， 无 论 是 客户 端 
视 ， 但 却 会 无 谓 地 导致 很 长 延迟 。 
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。 针对 协议 版 本 采取 优化 措施 
HTTP 1.x 支持 有 限 的 并 行 机 制 ， 要 求 打包 资源 、 跨 域 分 散 资源 ， 等 等 。 相 对 而 
言 ，HTTP 2.0 只 要 建立 一 个 连接 就 能 实现 最 优 性 能 ， 同 时 无 需 针 对 HTTP 1.x 的 
那些 优化 方法 。 


上 述 所 有 各 项 均 有 必要 详细 解释 。 下 面 我 们 分 别 讨论 。 


13.1.1 在 客户 端 缓存 资源 

要 说 最 快 的 网 络 请 求 ， 那 就 是 不 用 发 送 请 求 就 能 获取 资源 。 将 之 前 下 载 过 的 数据 组 
存 并 维护 好 ， 就 可 以 做 到 这 一 点 。 对 于 通过 HTTP 传输 的 资源 ， 要 保证 首部 包含 适 
当 的 缓存 字段 : 


。 Cache-Control 首部 用 于 指定 缓存 时 间 ， 
。 Last-Modified 和 ETag 首部 提供 验证 机 制 。 


只 要 可 能 ， 就 给 每 种 资源 都 指定 一 个 明确 的 缓存 时 间 。 这 样 客户 端 就 可 以 直接 使 用 
本 地 副本 ， 而 不 必 每 次 都 请 求 相同 的 内 容 。 类 似 地 ， 指 定 验证 机 制 可 以 让 客户 端 检 
查 过 期 的 资源 是 否 有 更 新 。 没 有 更 新 ， 就 没 必 要 重新 发 送 。 

最 后 ， 还 要 注意 应 同时 指定 缓存 时 间 和 验证 方法 ! 只 指定 其 中 之 一 是 最 常见 的 错误 ， 
于 是 要 么 导致 每 次 都 在 没有 更 新 的 情况 下 重 发 相同 内 容 (这 是 没有 指定 验证 ) ， 要 么 
导致 每 次 使 用 资源 时 都 多 余地 执行 验证 检查 (这 是 没有 指定 缓存 时 间 )。 


























理想 与 现实 : 智能 手机 上 的 Web 资源 缓存 


对 HTTP 最 早 的 版 本 而 言 ， 缓 存 HTTP 资源 一 度 是 最 最 重要 的 性 能 优化 措施 。 然 
而 ， 尽 管 看 似 所 有 人 部 意识 到 了 这 一 措施 的 好 处 ， 但 实际 调查 却 不 断 发 现 ， 缓 存 
资源 却 经 常 是 一 个 被 忽略 的 措施 | AT&T 实验 室 与 密 软 根 大 学 最 近 的 一 次 合作 研 
完 指出 : 
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我 们 对 两 个 数据 集 的 调查 表明 ， 宛 余 的 传输 分 别 占 据 相 应 HTTP 总 流量 
的 18% 和 20 史 。 这 些 额 外 传输 的 内 容 占 总 字 节 数 的 17% ， 耗 电 7%， 上 十 
信号 负载 的 6%， 在 第 二 个 数据 集 的 所 有 蜂窝 数据 流量 中 ， 占 无 线 资源 
的 9W%。 而 产生 这 些 宛 余 传输 的 主要 原因 ， 可 以 归结 为 智能 手机 Web 缓 
存 的 实现 未 能 完全 支持 或 者 严格 遵照 协议 规范 ， 或 者 开发 人 员 没 有 完全 
利用 相应 的 库 所 提供 的 缓存 功能 。 


Web Caching on Smartphones, MobiSys 2012 


你 的 应 用 在 一 遍 又 一 遍地 请 求 不 必要 的 资源 吗 ? 有 证 据 表 明 ， 提 出 这 个 问题 一 点 也 
不 可 笑 。 请 大 家 务必 对 自己 的 应 用 多 加 注意 ， 当 然 最 好 是 通过 测试 手段 来 保证 。 














13.1.2 ”压缩 传输 的 数据 

利用 本 地 缓存 可 以 让 客户 端 避 免 每 次 请 求 都 重复 取得 数据 。 不 过 ， 还 是 有 一 些 资源 
是 必须 取得 的 ， 比 如 原来 的 资源 过 期 了 ， 或 者 有 新 资源 ， 再 或 者 资源 不 能 缓 在 。 对 
于 这 些 资产， 应 该 保证 传输 的 字 节 数 最 少 。 因 此 要 保证 对 它们 进行 最 有 效 的 压缩 。 





HTML、CSS 和 JavaScript 等 文本 资源 的 大 小 经 过 gzip 压缩 平均 可 以 减少 60%~80%。 
而 图 片 则 需要 仔细 考量 : 


。 图 片 一 般 会 占 到 一 个 网 页 需要 传输 的 总 字 市 数 的 一 半 ， 
。 通过 去 掉 不 必要 的 元 数据 可 以 把 图 片 文件 变 小 ，; 

。 要 调整 大 小 就 在 服务 器 上 调整 ， 避 免 传输 不 必要 的 字 市 ; 
。 应 该 根据 图 像 选 择 最 优 的 图 片 格式 ， 

。 尽 可 能 使 用 有 损 压 缩 。 


不 同 图 片 格式 的 压缩 率 过 然 不 同 ， 因 为 不 同 的 格式 是 分 别 为 不 同 使 用 场景 设计 的 。 
事实 上 ， 如 果 选 错 了 图 片 格式 〈 比 如 ， 使 用 了 PNG 而 非 JPG 或 WebP)， 多 产生 几 
百 甚 至 上 千 KB 数据 是 轻而易举 的 事 。 建 议 大 家 多 找 一 些 工 具 和 自动 化 手段 ， 以 确 
定 最 佳 图 片 格式 。 


选 定 图 片 格式 后 ， 其 次 就 是 不 要 让 图 片 超过 它 需 要 的 大 小 。 如 果 在 客户 端 对 超出 需 
要 大 小 的 图 片 做 调整 ， 那 么 除了 额外 传输 不 必要 的 字 布 之 外 ， 还 会 浪费 CPU、GPU 
和 内 存 资源 (参见 11.6 节 的 “计算 图 片 对 内 存 的 需求 ”)。 


最 后 ， 选 择 了 正确 的 格式 ， 确 定 了 必需 的 大 小 ， 接 下 来 就 要 研究 使 用 哪 一 种 有 损 图 
片 格 式 ， 比 如 JPEG 还 是 WebP， 以 及 压缩 到 哪个 级 别 : 较 高 压缩 率 可 以 明显 减少 字 
节 数 ， 同 时 图 片 品质 不 会 有 太 大 或 太 明 显 的 损失 ， 尤 其 是 在 较 小 (手机) 的 屏幕 上 
看 ， 不 容易 发 现 。 
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WebP: Web 上 的 新 图 片 格式 


WebP 是 谷歌 开发 的 一 种 新 图 片 格 式 ， 得 到 了 Chrome 和 Opera 浏览 器 支持 。 这 种 
格式 的 无 损 压 缩 和 有 损 压 缩 效 能 都 有 所 提升 : 


。 WebP 的 无 损 压缩 图 片 比 PNG 的 小 26%; 
。 WebP 的 有 损 压 缩 图 片 比 JPG 的 小 25%~34%; 
。 WebP 支持 无 损 透 明 压 缩 ， 但 因此 仅 增 加 22% 的 字 节 。 


在 现 有 网 页 平均 1 MB 大小， 其 中 图 片 占 一 半 的 情况 下 ，WebP 节省 的 20%~30%， 
对 每 个 页 面 而 言 就 是 几 百 KB。 这 种 格式 需要 客户 端 CPU 多 花 点 时 间 解 码 (大 约 相 
当 于 处 理 JPG 的 1.4 倍 ) ， 但 字 节 的 节省 完全 可 以 补偿 处 理 时 间 的 增长 。 此 外 ， 由 于 
数据 流量 的 限制 和 高 速 网 络 的 存在 ， 对 很 多 用 户 而 言 ， 节 省 字 节 才 是 当务之急 。 
事实 上 ，Chrome Data Compression Proxy 和 Opera Turbo 等 工具 为 用 户 降低 带宽 
占用 的 主要 手段 ， 就 是 重新 把 每 张 图 片 编码 为 WebP 格式 。 正 常情 况 下 ，Chrome 
Data Compression Proxy 的 数据 压缩 率 可 以 达到 50%， 这 说 明 我 们 自己 的 应 用 也 有 
很 多 可 以 通过 压缩 提升 性 能 的 空间 。 











13.1.3 ”消除 不 必要 的 请 求 字 节 

HTTP 是 一 种 无 状态 协议 ， 也 就 是 说 服务 器 不 必 保 存 每 次 请 求 的 客户 端的 信息 。 然 
而 ， 很 多 应 用 又 依赖 于 状态 信息 以 实现 会 话 管理 、 个 性 化 、 分 析 等 功能 。 为 了 实现 
这 些 功 能 ，HTTP State Management Mechanism (RFC 2965) 作为 扩展 ， 人 允许 任何 
网 站 针对 自身 来 源 关 联 和 更 新 cookie 元 数据 : 浏 览 器 保存 数据 ， 而 在 随后 发 送 给 来 
源 的 每 一 个 请 求 的 cookie 首部 中 自动 附加 这 些 信息 。 


上 述 标准 并 未 规定 cookie 最 大 不 能 超过 多 大 ， 但 实践 中 大 多 数 浏 览 器 都 将 其 限制 为 
4 KB。 与 此 同时 ， 该 标准 还 规定 每 个 站 点 针对 其 来 源 可 以 有 多 个 关联 的 cookie。 于 
是 ， 一 个 来 源 的 cookie 就 有 可 能 多 达 几 十 KB ! 不 用 说 ， 这 么 多 元 数据 随 请 求 传 
递 ， 必 然 会 给 应 用 带 来 明显 的 性 能 损失 : 


。 浏览 器 会 在 每 个 请 求 中 自动 附加 关联 的 cookie 数据 

。 在 HTTP 1.x 中 ,包括 cookie 在 内 的 所 有 HTTP 首部 都 会 在 不 压缩 的 状态 下 传输 ; 
。 在 HTTP 2.0 中 ， 这 些 元 数据 经 过 压缩 了 ， 但 开销 依然 不 小 ; 

。 最 坏 的 情况 下 ， 过 大 的 HTTP cookie 会 超过 初始 的 TCP 拥塞 窗口 ， 从 而 导致 多 
余 的 网 络 往返 。 


应 该 认真 对 待 和 监控 cookie 的 大 小 ， 确 保 只 传输 最 低 数量 的 元 数据 ， 比 如 安全 会 话 
令 牌 。 同 时 ， 还 应 该 利用 服务 器 上 共享 的 会 话 缓存 ， 从 中 查询 缓存 的 元 数据 。 更 好 
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的 结果 ， 则 是 完全 不 用 cookie。 比 如 ， 在 请 求 图 片 、 脚 本 和 样式 表 等 静态 资源 时 ， 
浏览 器 绝 大 多 数 情况 下 不 必 传 输 特定 于 客户 端的 元 数据 。 














4 4 ， 务 器 。 这 个 服务 器 可 以 用 于 交付 那些 不 区 分 客户 端的 共用 资源 。 


0, 








y 3 
一 ] 在 使 用 HTTP 1.x 的 情况 下 ， 可 以 指定 一 个 专门 的 “无 需 cookie” 的 来 源 服 


13.1.4 并 行 处 理 请 求 和 响应 

为 了 让 应 用 响应 速度 达到 最 快 ， 应 该 尽 可 能 第 一 时 间 就 分 派 所 有 资源 请 求 。 可 是 ， 
还 有 一 点 也 要 考虑 到 ， 那 就 是 所 有 这 些 请 求 以 及 它们 对 应 的 响应 ， 将 会 被 服务 器 如 
何 处 理 。 如 果 我 们 的 请 求 在 服务 器 上 按 先 来 后 到 的 顺序 依次 排队 ， 那 就 又 会 导致 不 
必要 的 延迟 。 要 是 想 实 现 最 佳 性 能 ， 就 要 记 住 以 下 几 点 : 








。 使 用 持久 连接 ， 从 HTTP 1.0 升级 到 HTTP 1.1; 
。 利用 多 个 HTTP 1.1 连接 实现 并 行 下 载 ; 

。 可 能 的 情况 下 利用 HTTP 1.1 管道 ， 

。 考虑 升级 到 HTTP 2.0 以 提升 性 能 ; 

。 确保 服务 器 有 足够 的 资源 并 行 处 理 请 求 。 


如 果 不 使 用 持久 连接 ， 则 每 个 HTTP 请 求 都 要 建立 一 个 TCP 连接 。 由 于 TCP 握手 
和 慢 启 动 ， 多 个 TCP 会 造成 明显 的 延迟 。 在 使 用 HTTP 1.1 的 情况 下 ， 最 好 尽 可 能 
重用 已 有 连接 。 如 果 磁 上 能 使 用 HTTP 管道 的 机 会 ， 不 要 放 过 。 更 好 的 选择 ， 则 是 
升级 到 HTTP 2.0， 从 而 获得 最 佳 性 能 。 


识别 造成 客户 端 和 服务 器 延迟 的 不 必要 资源 既是 艺术 也 是 技术 : 要 仔细 检查 客户 端 
资源 瀑布 (参见 10.2.2 市 “分 析 资 源 瀑布 ")， 以 及 服务 器 日 志 。 常 见 问 题 如 下 : 
。 服务 器 资源 不 足 ， 造 成 不 必要 的 资源 处 理 延 迟 ，; 


。 代理 及 负载 均衡 器 容量 不 足 ， 造 成 向 应 用 服务 器 交付 请 求 的 延迟 〈 请 求 排队 ) ， 
。 客户 端 资源 阻塞 导致 页 面 构建 延迟 ， 参 见 10.1 节 的 “DOM、CSSOM 和 JavaScript”。 








优化 浏览 器 中 的 资源 加 载 
浏览 器 会 自动 确定 文档 中 每 个 资源 的 最 优 加 载 顺序 ， 但 我 们 可 以 为 浏览 器 提供 辅 
助 ， 也 可 以 给 它 帮 倒 忙 : 
。 可 以 为 浏览 器 给 出 提示 ， 参 见 10.5 节 “ 针 对 浏览 器 的 优化 建议 ”; 
。 可 以 通过 藏匿 资源 来 干扰 浏览 器 。 
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现代 浏览 器 都 会 尽 可 能 高 效 迅 速 地 扫描 HIML 和 CSS 文件 内 容 。 可 是 ， 文 档 解 析 
器 也 会 因为 下 载 脚 本 或 其 他 阻塞 资源 而 被 人 迫 等 待 。 此 时 ， 浏 览 器 会 使 用 “ 预 加 载 
扫描 器 ”， 推 测 有 哪些 资源 要 下 载 ， 从 而 尽早 分 派 请 求 ， 以 减少 总 体 延 迟 。 

但 使 用 预 加 载 扫 描 器 是 一 种 推测 性 优化 ， 而 且 只 会 在 文档 解析 器 被 阻塞 的 情况 下 
才 会 使 用 。 实 践 表明 ， 这 种 推测 性 优化 效果 很 好 : 根据 谷歌 Chrome 的 试验 性 数 
据 ， 这 种 优化 能 把 页 面 加 载 时 间 和 洽 染 速度 提高 约 209% | 

可 惜 的 是 ， 这 种 优化 不 适合 通过 JavaScript 调度 的 资源 。 毕 竟 预 加 载 扫描 器 不 能 预 
先 执行 脚本 啊 。 结 果 ， 通 过 脚本 来 调度 资源 虽然 可 以 更 细 化 地 控制 应 用 ， 但 也 向 
预 加 载 扫 描 器 藏匿 了 资源 ， 这 种 做 法 的 得 失 还 要 仔细 地 权衡 。 








13.2 ”针对 HTTP 1.x 的 优化 建议 


针对 HTTP 1.x 的 优化 次 序 很 重要 : 首先 要 配置 服务 器 以 最 大 限度 地 保证 TCP 和 
TLS 的 性 能 最 优 ， 然 后 再 谨慎 地 选择 和 采用 移动 及 经 典 的 应 用 最 佳 实践 ， 之 后 再 度 
量 ， 迭 代 。 

采用 了 经 典 的 应 用 优化 措施 和 适当 的 性 能 度量 手段 ， 还 要 进一步 评估 是 否 有 必要 为 
应 用 采取 特定 于 HTTP 1.x 的 优化 措施 (其 实 是 权宜 之 计 )。 

。 利用 HTTP 管 道 


如 果 你 的 应 用 可 以 控制 客户 端 和 服务 器 这 两 端 ， 那 么 使 用 管道 可 以 显著 减少 网 络 
延迟 。 





。 采用 域名 分 区 
如 果 你 的 应 用 性 能 受 限 于 默认 的 每 来 源 6 个 连接 ， 可 以 考虑 将 资源 分 散 到 多 个 
来 源 。 


。 打包 资源 以 减少 HTTP 请 求 
拼接 和 精灵 图 等 技巧 有 助 于 降低 协议 开销 ， 又 能 达成 类 似 管 


。 嵌入 小 资源 
芳 虑 直接 在 父 文档 中 藤 入 小 资源 ， 从 而 减少 请 求 数量 。 


管道 缺乏 支持 ， 而 其 他 优化 手段 又 各 有 各 的 利 整 。 事 实 上 ， 这 些 优化 措施 如 果 过 于 
激进 或 使 用 不 当 ， 反 倒 会 伤害 性 能 〈 这 一 点 请 参考 第 11 章 的 深入 讨论 )。 总 之 ， 要 
有 务实 的 态度 ， 通 过 度量 来 评估 各 种 措施 对 性 能 的 影响 ， 在 此 基础 上 再 迭代 改进 。 
天 底下 就 没有 包 治 百 病 的 灵丹妙药 。 
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对 了 ， 还 有 最 后 一 招 儿 一 一 升级 到 HTTP 2.0。 仅 此 一 招 儿 抵 得 上 前 面 提 到 
人 4。 ， 的 大 多 数 针对 HTTP 1.x 的 优化 手段 ! HTTP 2.0 不 光 能 让 应 用 加 载 更 快 ， 
尾 ， 还 能 让 开发 更 简单 。 








13.3 ”针对 HTTP 2.0 的 优化 建议 


HTTP 2.0 的 主要 目标 就 是 提升 传输 性 能 ， 实 现 客户 端 与 服务 器 间 较 低 的 延迟 和 较 高 
的 吞吐 量 。 显 然 ， 在 TCP 和 TLS 之 上 实现 最 佳 性 能 ， 同 时 消除 不 必要 的 网 络 延 迟 ， 
从 来 没有 如 此 重要 过 。 最 低 限 度 : 

。 服务 器 的 初始 cwnd 应 该 是 10 个 分 组 ， 

。 服务 器 应 该 通过 ALPN (针对 SPDY 则 为 NPN) 协商 支持 TLS; 

。 服务 器 应 该 支持 TLS 恢复 以 最 小 化 握手 延迟 。 





简 言 之 ， 请 回顾 2.5 节 “ 针 对 TCP 的 优化 建议 ”和 4.7 节 “ 针 对 TLS 的 优化 建议 ”。 
要 通过 HTTP 2.0 获得 最 佳 性 能 ， 特 别 是 从 每 个 来 产 仅 用 一 个 连接 的 角度 说 ， 的 确 
需要 各 层 协议 的 紧密 配合 。 


接 下 来 ， 或 许 有 点 意外 ， 那 就 是 采用 移动 及 其 他 经 典 的 最 佳 做 法 : 少 发 数据 、 削 减 
请 求 ， 根 据 无 线 网 络 情况 调整 资源 供给 。 不 管 使 用 什么 版 本 的 协议 ， 减 少 传输 的 数 
气量 和 消除 不 必要 的 网 络 延迟 ， 对 任何 应 用 都 是 最 有 效 的 优化 手段 。 


最 后 ， 杜 绝 和 忘记 域名 分 区 、 0 i nh ne 
HTTP 2.0 之 上 完全 没有 必要 。 事 实 上 ， 继 续 使 用 这 些 手 段 反 而 有 害 ! 可 以 利用 
HTTP 2.0 内 置 的 多 路 分 发 以 及 服务 器 推送 等 




















致 HTTP 2.0 和 SPDY 早期 采用 者 


官方 HTTP 2.0 标准 还 在 制定 中 。 在 此 期 间 ，SPDY 是 这 个 协议 的 “应 用 ”版 ( 参 
OR et gh Be Ga 


持 ， 并 在 几 年 里 基于 真实 的 应 用 提供 反馈 。 如 果 你 是 一 位 早期 采用 者 ， 那 你 肯定 
在 一 家 好 公司 。 
最 后 ， 虽 然 SPDY 和 HTTP 2.0 规范 并 不 完全 同步 ， 但 它们 却 有 相同 的 核心 功能 和 


优化 。 我 们 在 这 里 以 及 之 前 几 节 讨论 ee 同样 适用 。 











13.3.1 去 掉 对 1.x 的 优化 
针对 HTTP 2.0 和 HTTP 1.x 的 优化 策略 没有 什么 重 琶 。 因 此 ， 不 仅 不 必 担 心 HTTP 
1.x 协议 的 种 种 限制 ， 而 且 要 撤销 原先 那些 必要 的 做 法 。 
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。 每 个 来 源 使 用 一 个 连接 
HTTP 2.0 通过 将 一 个 TCP 连接 的 吞吐 量 最 大 化 来 提升 性 能 。 事 实 上 ， 在 HTTP 
2.0 之 下 再 使 用 多 个 连接 (比如 域名 分 区 ) 反倒 成 了 一 种 反 模 式 ， 因 为 多 个 连接 
会 抵消 新 协议 中 首部 压缩 和 请 求 优 先 级 的 效用 。 


。 去 挤 不 必要 的 文件 合并 和 图 片 拼接 
打包 资源 的 缺点 很 多 ， 比 如 缓存 失效 、 占 用 内 存 、 延 缓 执行 ， 以 及 增加 应 用 复杂 
性 。 有 了 HTTP 2.0， 很 多 小 资源 都 可 以 并 行 发 送 ， 导 致 打包 资源 的 效率 反而 更 低 。 


。 利用 服务 器 推送 
之 前 针对 HTTP 1.x 而 戏 入 的 大 多 数 资 源 ， 都 可 以 而 且 应 该 通过 服务 器 推送 来 交 
付 。 这 样 一 来 ， 客 户 端 就 可 以 分 别 缓存 每 个 资源 ， 并 在 页 面 间 实 现 重用 ， 而 不 必 
把 它们 放 到 每 个 页 面 里 了 。 


要 获得 最 佳 性 能 ， 应 该 尽 可 能 把 所 有 资源 都 集中 在 一 个 域名 之 下 。 域 名 分 区 在 HITP 
2.0 之 下 属于 反 模 式 ， 对 发 挥 协议 的 性 能 有 害 : 分 区 是 开始 ， 之 后 影响 会 逐渐 扩散 。 
ws 





丧 六 





芭 关于 合并 文件 和 拼接 图 片 的 负面 影响 ， 请 参考 11.6 节 “ 连 接 与 拼合 ”"， 以 

心 及 该 节 中 的 “计算 图 片 对 内 存 的 需求 ”。 
DSN 

类 似 地 ， 把 嵌入 资源 改 为 服务 器 推送 能 提升 客户 端的 缓存 性 能 ， 又 不 会 导致 额外 网 

络 延 迟 (参见 12.3.7 节 中 的 “实现 HTTP 2.0 服务 器 推送 ”)。 事 实 上 ， 由 于 3G 和 

4G 网 络 的 往返 时 间 更 长 ， 因 而 服务 器 推送 对 移动 应 用 来 说 效果 更 明显 。 


























HTTP 2.0 中 的 打包 与 协议 开销 


由 于 HTTP 1.x 做 不 到 多 路 复 用 ， 而 且 每 次 请 求 的 协议 开销 很 高 ， 这 才 有 了 连接 和 
拼合 等 打包 技术 。 在 HTTP 2.0 之 下 ， 多 路 复 用 已 经 不 成 问题 ， 首 部 压缩 也 可 以 降 
低 每 次 HTTP 请 求 要 传输 的 元 数据 量 ， 打 包 技 术 在 多 数 情 况 下 都 不 再 需要 了 。 

不 过 ， 请 求 开 销 只 是 减少 了 ， 并 没有 等 于 零 。 少 数 情况 下 ， 菜 些 资源 必须 一 块 使 
用 ， 而 且 更 新 也 不 频繁 ， a 
见 ， 可 以 算 作 例外 。 有 具体 措施 可 以 通过 性 能 度量 确定 。 











13.3.2” 双 协议 应 用 策略 
遗憾 的 是 ， 升 级 到 HTTP 2.0 不 会 在 一 夜 之 间 完 成 。 因 此 ,很 多 应 用 都 需要 认真 学 
虑 双 协 议 并 存 的 部 署 策 略 ， 即 同一 个 应 用 既 能 通过 HTTP 1.x 交付 ， 也 能 通过 HTTP 
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2.0 交 付 ， 无 需 任 何 改动 。 然 而 ， 过 于 激进 的 HTTP 1.x 优化 可 能 伤害 HTTP 2.0 性 
能 ， 反 之 亦 然 。 

如 果 应 用 可 以 同时 控制 服务 器 和 客户 端 ， 那 倒 简单 了 ， 因 为 它 可 以 决定 使 用 什么 协 
议 。 但 大 多 数 应 用 不 能 也 无 法 控制 客户 端 ， 只 有 采用 一 种 混合 或 自动 策略 ， 以 适应 
两 种 协议 并 存 的 现实 。 下 面 我 们 就 分 析 几 种 可 能 的 情况 。 


相同 的 应 用 代码 ， 双 协议 部 署 

相同 的 应 用 代码 可 能 通过 HTTP 1.x 也 可 能 通过 HTTP 2.0 交付 。 可 能 任何 一 种 
协议 之 下 都 达 不 到 最 佳 性 能 ， 但 可 以 追求 性 能 足够 好 。 所 谓 足 够 好 ， 需 要 通过 针 
对 每 一 种 应 用 单独 度量 来 保证 。 这 种 情况 下 ， 第 一 步 可 以 先 撤 销 域名 分 区 以 实现 
HTTP 2.0 交付 。 然 后 ， 随 着 更 多 用 户 迁 移 到 HTTP 2.0， 可 以 继续 撤销 资源 打包 
并 尽 可 能 利用 服务 器 推送 。 


分 离 应 用 代码 ， 双 协议 部 署 

根据 协议 不 同 分 别 交付 不 同 版 本 的 应 用 。 这 样 会 增加 运 维 的 复杂 性 ， 但 实践 中 对 
很 多 应 用 倒是 十 分 可 行 。 比 如 ， 一 台 负 责 完成 连接 的 边界 服务 器 可 以 根据 协商 后 
的 协议 版 本 ， 把 客户 端 请 求 引导 至 适当 的 服务 器 

















动态 HTTP 1.x 和 HTTP 2.0 优 化 

某 些 自动 化 的 Web 优化 框架 ， 以 及 开源 及 商业 产品 ， 都 可 以 在 响应 请 求 时 动态 
重 写 交付 的 应 用 代码 (包括 连接 、 拼 合 、 分 区 ， 等 等 )。 此 时 ， 服 务 器 也 可 以 考 
虑 协商 的 协议 版 本 ， 并 动态 采用 适当 的 优化 策略 。 


。 HTTP 2.0， 单 协议 部 署 


如 果 应 用 可 以 控制 服务 器 和 客户 端 ， 那 没 理由 不 只 使 用 HTTP 2.0。 事 实 上 ， 如 
果真 有 这 种 可 能 ， 那 就 应 该 专 一 使 用 HTTP 2.0。 





选择 路 线 时 ， 要 看 当前 的 基础 设施 、 应 用 的 复杂 程度 ， 以 及 用 户 的 构成 。 让 人 哭 笑 
不 得 的 是 ， 那 些 在 HTTP 1.x 优化 上 投资 很 大 的 应 用 ， 反 倒 在 这 种 情况 下 最 难 办 。 
如 果 你 能 控制 客户 端 ， 有 自动 的 应 用 优化 策略 ， 或 者 没有 使 用 任何 特定 于 1.x 的 优 
化 ， 那 么 就 可 以 专注 于 HTTP 2.0， 而 没有 后 顾 之 忧 了 。 














使 用 PageSpeed 实现 动态 优化 


谷歌 的 PageSpeed Optimization Libraries (PSOL) 提供 了 40 多 种 “Web 优化 过 滤 
器 ”的 开源 实现 ， 可 以 集成 到 任何 服务 器 运行 时 ,动态 应 用 各 种 优化 策略 。 
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在 使 用 PSOL 库 的 情况 下 ，mod_pagespeed (Apache) 和 ngx_pagespeed (Nginx) 
模块 都 可 以 基于 指定 的 优化 过 滤器 (如 点 入 、 压 缩 、 拼 接 、 分 片 等 ) 实现 动态 重 
写 ， 并 优化 资源 交付 方式 。 每 次 优化 都 在 请 求 时 动态 应 用 (并 被 缓存 ) ， 整 个 优化 
过 程 完全 自动 化 了 。 


在 动态 优化 下 ， 服 务 器 还 可 以 根据 所 用 协议 ， 黄 至 用 户 代 理 的 类 型 和 版 本 调整 优 
化 策略 。 比 如 ， 可 以 配置 mod_pagespeed 模块 ， 在 客户 说 使 用 HTTP 2.0 时 跳 过 某 
些 优化 : 


# 对 SPDY/HTTP 2.9 客户 端 禁 用 拼接 
<ModPagespeedIf spdy> 

ModPagespeedDisableFilters combine css,combine javascript 
</ModPagespeedIf> 

















# 只 对 HTTP 1.x 客户 端 使 用 域名 分 区 
<ModPagespeedIf !spdy> 

ModPagespeedShardDomain www.site.com si1.site.com,s2.site.com 
</ModPagespeedIf> 





使 用 PageSpeed 这 样 的 自动 Web 优化 库 ， 可 以 让 我 们 省 去 不 少 麻烦 ， 值 得 考虑 。 





13.3.3 1.x 与 2.0 的 相互 转换 
除了 双 协 议 优 化 策略 ， 很 多 已 部 署 的 应 用 都 需要 在 自己 的 应 用 服务 器 上 采取 一 种 折 
中 方案 : 两 端 都 是 HTTP 2.0 是 追求 最 佳 性 能 的 目标 ， 但 〈 新 增 ) 一 个 转换 层 (图 
13-2) 也 可 以 让 1.x 服务 器 利用 HTTP 2.0。 





HTTP 1.x 服 务 器 


HTTP 2.0 
-一 一 一 





HTTP 1.x 服 务 器 











图 13-2: HTTP 2.0 到 1.x 的 转换 ， 即 将 流转 换 为 1.x 请 求 


一 人 台 居 间 服 务 器 可 以 接受 HTTP 2.0 会 话 ， 处 理 之 后 再 向 既 有 基础 设施 分 派 1.x 格式 
的 请 求 。 接 到 响应 后 ， 再 将 其 转换 成 HTTP 2.0 的 流 并 返回 客户 端 。 通 常 ， 这 是 应 
用 HTTP 2.0 更 新 的 最 简单 方式 ， 因 为 这 样 可 以 重用 已 有 的 1.x 基础 设施 ， 而 且 基 本 
不 用 修改 。 
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大 多 数 支 持 HTTP 2.0 的 Web 服务 器 默认 都 提供 2.0 到 1.x 的 转换 机 制 : 
心 。2.0 会 话 终止 于 服务 器 (Apache 或 Nginx)， 如 果 服 务 器 被 配置 为 反 向 代 
全 ， 理 ， 那 么 分 派 给 具体 应 用 服务 器 的 就 是 1.x 请 求 。 














然而 ，2.0 到 1.x 的 这 种 简单 策略 并 非 长 久之 计 。 从 很 多 方面 来 说 ， 这 种 工作 流 实 
际 是 一 种 倒退 。 真 正 正 确 的 做 法 ， 不 是 把 优化 的 、 可 复 用 的 会 话 转换 成 一 系列 1.x 
请 求 ， 因 基础 设施 而 废 优化 ， 而 是 相反 : 把 接收 到 的 1.x 客户 端 请 求 转换 成 2.0 流 ， 
并 把 我 们 的 基础 设施 标准 化 ， 使 其 在 任何 时 候 都 处 理 2.0 会 话 。 


为 获得 最 佳 性 能 ， 同 时 实现 低 延 迟 和 实时 的 Web 应 用 ， 应 该 要 求 我 们 的 内 部 基础 设 
施 达到 如 下 标准 : 

。 负载 均衡 器 和 代理 与 应 用 的 连接 应 该 持久 化 ， 

。 请 求 和 响应 流 及 多 路 复 用 应 该 是 默认 配置 ， 

。 与 应 用 服务 器 的 通信 应 该 基于 消息 ， 

。 客户 端 与 应 用 服务 器 的 通信 应 该 是 双向 的 。 


端 到 端的 HTTP 2.0 会 话 符合 上 述 所 有 条 件 ， 能 实现 对 客户 端 以 及 数据 中 心 内 部 的 
低 延 迟 交 付 : 无 需 定 制 的 RPC 层 及 相应 机 制 ， 就 能 实现 内 部 服务 之 间 的 通信 ， 并 
获得 理想 的 性 能 。 简 言 之 ， 不 要 把 2.0 降级 到 1.x， 这 不 是 长 久之 计 。 长 久之 计 是 把 
1.x 升级 到 2.0， 这 样 才能 求 得 最 佳 性 能 。 


13.3.4 评估 服务 器 质量 与 性 能 

HTTP 2.0 服务 器 实现 的 质量 对 客户 端 性 能 影响 很 大 。HTTP 服务 器 的 配置 当然 是 一 
个 重要 因素 ,但 服务 器 实现 逻辑 的 质量 同样 与 优先 级 、 服 务 器 推送 、 多 路 复 用 等 性 
能 机 制 的 发 挥 紧密 相关 。 


。 HTTP 2.0 服务 器 必须 理解 流 优先 级 ; 

。 HTTP 2.0 服务 器 必须 根据 优先 级 处 理 响应 和 交付 资源 ， 

。 HTTP 2.0 服务 器 必须 支持 服务 器 推送 ; 

。 HTTP 2.0 服务 器 应 该 提供 不 同 推送 策略 的 实现 。 

HTTP 2.0 服务 器 的 初级 实现 也 能 支持 某 些 功能 ， 但 不 能 明确 支持 请 求 的 优先 级 和 服 
务 器 推送 ， 可 能 导致 次 优 性 能 。 比 如 ， 发 送 大 型 、 静 态 图 片 导 致 带宽 饱和 ， 而 客户 
端 又 因为 其 他 重要 资源 (如 CSS 或 JavaScript) 被 阻塞 。 















































地 。， 

为 尽 可 能 获得 最 佳 性 能 ，HTTP 2.0 客户 端 必须 是 个 “乐观 主义 者 ”: 尽 可 
心 能 早 地 发 送 所 有 请 求 ， 然 后 完全 听任 服务 器 的 优化 。 事 实 上 ，HTTP 2.0 客 
户 端 对 服务 器 的 依赖 程度 较 之 以 前 更 甚 。 
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类 似 地 ， 不 同 的 服务 器 可 能 提供 利用 服务 器 推送 的 不 同 机 制 和 策略 (参见 12.3.7 节 
中 的 “实现 HTTP 2.0 服务 器 推送 ”)。 如 果 说 你 的 应 用 性 能 与 HTTP 2.0 服务 器 的 质 
量 紧 密 相 关 ， 是 一 点 也 不 夸张 的 。 
“ ~ 鉴于 HTTP 2.0 和 SPDY 的 迅速 发 展 ， 不 同 服务 器 (Apache、Nginx、Jetty 
| 等 ) 对 HTTP 2.0 的 实现 还 处 于 不 同 的 阶段 。 要 了 解 它们 当前 支持 的 功能 
发， 和 最 新 消息 ， 请 查阅 相应 的 文档 和 发 版 说 明 。 





13.3.5 2.0 与 TLS 

实践 中 ， 由 于 存在 很 多 不 兼容 的 中 间 代 理 ， 早 期 的 HTTP 2.0 部 署 必然 依赖 加 密 信 
道 。 这 样 一 来 ， 我 们 就 面临 两 种 可 能 出 现 ALPN 协商 和 TLS 终止 的 情况 : 

。 TLS 连接 可 能 会 在 HTTP 2.0 服务 器 上 终止 ; 

。 TLS 连接 可 能 会 在 上 游 (如 负载 均衡 器 ) 上 终止 。 

第 一 种 情况 要 求 HTTP 2.0 服务 器 能 够 处 理 TLS， 除 此 之 外 就 没有 什么 了 。 第 二 种 
情况 复杂 一 些 : TLS+ALPN 握手 可 能 会 在 上 游 代理 处 终止 (图 13-3)， 然 后 再 从 那 
里 建立 一 条 加 密 信道 ， 或 者 直接 将 非 加 密 的 HTTP 2.0 流 发 送 到 服务 器 。 











HTTP 2.x 服 务 器 








HTTP 2.0 







HTTPS1.1 
一 一 一 






TLS 终 止 ， 
代理 + 负载 均衡 器 HTTP 1.x 服 务 器 














13-3; 支持 TLS+ALPN 的 负载 均衡 器 


代理 和 应 用 服务 器 之 间 使 用 安全 信道 还 是 非 加 密 信 道 ， 取 决 于 应 用 : 只 要 能 控制 
中 间 设 备 ， 就 可 以 保证 未 加 密 的 帧 不 会 被 修改 或 丢弃 。 那 么 ， 虽 然 大 多 数 HTTP 
2.0 服务 器 都 应 该 支持 TLS+ALPN 协商 ， 但 它们 同时 也 应 该 在 不 加 密 的 情况 下 实现 
HTTP 2.0 通信 。 




















另外 ， 智 能 负载 均衡 器 也 可 以 使 用 TLS+ALPN 协商 机 制 ， 根 据 协商 后 的 协议 ， 选 择 
性 地 将 不 同 的 客户 端 路 由 到 不 同 的 服务 器 。 
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Fe 
; HAProxy 是 一 个 流行 的 开源 负载 均衡 器 ， 同 时 支持 NPN 协商 和 基于 协商 
心 后 协议 的 路 由 。 我 的 这 篇 文章 是 一 个 简单 的 介绍 :“Simple SPDY and NPN 


‘ > Negotiation with HAProxy” (http://hpbn.co/haproxy-npn)。 





13.3.6 ”负载 均衡 器 、 代 理 及 应 用 服务 器 
根据 现 有 基础 设施 以 及 应 用 的 复杂 程度 和 规模 ， 你 的 基础 设施 中 可 能 需要 一 台 或 多 
台 负 载 均衡 器 (图 13-4) 或 者 HTTP 2.0 代理 。 





TLS+ALPN 
HTTP2.0 服 务 器 


HTTP 2.0 


TLS+ALPN 
HTTP 2.0 服 务 器 


负载 均衡 器 ou 0 TLS+ALPN 
HTTP2.0 HTTP 2.0 服 务 器 
非 加 密 的 HTTP 2.0 服 务 器 


<> 
全 
< 


HTTP 2.0 











13-4: 负载 均衡 器 与 TLS 终止 策略 

最 简单 的 情况 下 ，HTTP 2.0 服务 器 与 客户 端 直接 对 话 ， 并 负责 完成 TLS 连接 ， 进 
行 ALPN 协商 ， 以 及 处 理 所 有 请 求 。 

然而 ， 一 台 服 务 器 对 于 大 型 应 用 是 不 够 的 。 大 型 应 用 必须 要 添加 一 台 负 载 均 衡器 
以 分 流 大 量 请 求 。 此 时 ， 负 和 载 均 衡器 可 以 终止 TLS 连接 (参见 13.3.5 节 “2.0 与 
TLS”)， 也 可 以 经 过 配置 作为 TCP 代理 并 直接 将 加 密 数 据 发 送 给 应 用 服务 器 





有 


很 多 云 提 供 商 也 会 提供 负载 均衡 器 服务 。 然 而 ， 这 些 负载 均衡 器 大 多 支持 

4% 4 、TLS 终止 ， 却 不 支持 ALPN 协商 ， 而 这 对 于 通过 TLS 实现 HTTP 2.0 通信 

全 "是 必需 的 。 在 这 种 情况 下 ， 应 该 将 负载 均衡 器 配置 为 TCP 代理 ， 即 通过 它 
们 将 加 密 数 据 发 送 给 应 用 服务 器 ， 让 应 用 服务 器 完成 TLS+ALPN 协商 。 
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实践 中 ， 要 回答 的 最 重要 的 一 个 问题 ， 就 是 你 的 基础 设施 中 的 哪个 组 件 负 责 终止 
TLS 连接 ， 以 及 它 是 否 能 够 执行 必要 的 ALPN 协商 ? 








。 要 在 TLS 之 上 实现 HTTP 2.0 通信 ， 终 端 服务 器 必须 支持 ALPN 

。 尽 可 能 在 接近 用 户 的 地 方 终止 TLS， 参 见 4.7.2 节 “ 尽 早 完 成 (握手 )”， 

。 如 果 无 法 支持 ALPN， 那 么 选择 TCP 负载 均衡 模式 ; 

。 如 果 无 法 支持 ALPN 且 TCP 负载 均衡 也 做 不 到 ， 那 么 就 退 而 求 其 次 ， 在 非 加 密 
信道 上 使 用 HTTP 的 Upgrade 流 , 参见 12.3.9 节 “ 有 效 的 HTTP 2.0 升级 与 发 现 ”。 
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第 四 部 分 





浏览 器 API 与 协议 


第 14 章 


浏 扣 器 网 络 概述 





作为 一 个 平台 ,现代 浏览 器 是 专门 设计 用 来 快速 、 高 效 、 安 全 地 交付 Web 应 用 的 。 
事实 上 ， 在 其 表面 之 下 ， 现 代 浏 览 器 完全 是 一 个 陡 括 数 百 个 组 件 的 操作 系统 ， 包 括 
进程 管理 、 安 全 沙 箱 、 分 层 的 优化 缓存 、JavaScript 虚拟 机 、 图 形 泻 染 和 GPU 管 
道 、 存 储 系 统 、 传 感 器 、 音 频 与 视频 、 网 络 机 制 ， 等 等 。 


显然 ， 浏 览 器 乃至 运行 在 其 中 的 应 用 的 性 能 ， 取 决 于 若干 组 件 : 解析 、 布 局 、 
HTML 与 CSS 的 样式 计算 、JavaScript 执行 速度 、 泻 染 管道 ， 当 然 还 有 网 络 相 关 各 
层 协议 的 配合 。 其 中 每 个 组 件 的 角色 都 很 重要 ， 而 网 络 组 件 通常 是 加 倍 重要 ， 因 为 
浏览 器 慢 就 慢 在 等 待 网 络 资源 上 ， 等 待 造成 后 续 环 市 被 阻塞 | 


自然 地 ， 现 代 浏 览 器 对 各 层 网 络 协议 的 实现 也 就 远 不 止 一 个 套 接 字 管 理 器 那么 简单 。 
从 外 界 看 ， 可 以 把 网 络 组 件 当成 一 个 简单 的 获取 机 制 ， 但 从 内 部 看 ， 它 本 身 又 是 一 
个 平台 的 概念 (图 14-1) ， 有 自己 的 优化 条 件 、API 和 服务 。 


设计 Web 应 用 的 时 候 ， 我 们 不 必 关 心 个 别 的 TCP 或 UDP 套 接 字 ， 浏 览 器 会 不 我 们 
管理 它们 。 而 且 ， 网 络 组 件 会 帮 我 们 施加 恰当 的 连接 限制 、 格 式 化 请 求 、 隔 离 应 用 、 
管理 代理 、 缓 在， 等 等 。 在 隐藏 了 这 些 复杂 性 的 基础 上 ， 我 们 才 可 以 专注 于 自己 的 
应 用 逻辑 。 


可 是 ， 眼 不 见 不 意味 着 心 不 烦 ! 前 面 已 经 讨论 过 了 ， 理 解 TCP、HTTP， 还 有 移动 


网 络 的 性 能 特点 ， 有 助 于 我 们 构建 更 快 的 应 用 。 同 理 ， 理 解 如 何 最 恰当 地 利用 浏览 
器 的 网 络 API、 协 议和 服务 ， 照 样 能 给 应 用 带 来 显著 的 性 能 提升 。 
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HTTP 1.x/2.0 
缓存 、cookie 管 理 、 代 理 逻 辑 等 WebRTC 


同 源 策略 及 安全 沙 箱 


套 接 字 管理 及 优化 


TCP. TLS. UDP. DNS 














14-1: 高 层 浏览 器 网 络 API、 协 议和 服务 


14.1 连接 管理 与 优化 


运行 在 浏览 器 中 的 web 应 用 并 不 负责 管理 个 别 网 络 套 接 字 的 生命 周期 ， 这 是 好 事 。 通 
过 把 这 个 任务 委托 给 浏览 器 ， 可 以 自动 化 很 多 重要 的 性 能 优化 任务 ， 包 括 套 接 字 重 
用 、 请 求 优先 级 排 定 、 晚 绑 定 、 协 议 协 商 、 施 加 连接 数 限 制 ， 等 等 。 事 实 上， 浏览 
器 是 有 意 把 请 求 管 理 生命 周期 与 套 接 字 管理 分 开 的 。 这 一 点 很 微妙 ， 但 却 至 关 重 要 。 








套 接 字 是 以 池 的 形式 进行 管理 的 (图 14-2)， 即 按照 来 源 ， 每 个 池 都 有 自己 的 连接 限制 
和 安全 约束 。 挂 起 的 请 求 是 排 好 队 的 、 有 优先 次 序 的 ， 然 后 再 适时 把 它们 绑 定 到 池 中 个 
别 的 套 接 字 上 。 除 非 服 务 器 有 意 关闭 连接 ， 否 则 同一 个 套 接 字 可 以 自动 用 于 多 个 请 求 ! 











| | 






A 页 面 请 求 队列 N 页 面 请 求 队列 














套 接 字 管 理 器 


(http, siteN.com, 80) 








(https, siteA.com, 443) 





(http, siteC.com, 80) 
套套 信访 











中 


14-2: 自动 管理 的 套 接 字 池 在 所 有 浏览 器 进程 间 共 
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。 来 源 
由 应 用 协议 、 域 名 和 端口 三 个 要 件 构 成 ， 比 如 (http, www.example.com, 80) 与 
(https, www.example.com, 443) 就 是 两 个 不 同 的 来 源 。 


。 套 接 字 池 
属于 同一 个 来 源 的 一 组 套 接 字 。 实 践 中 ， 所 有 主流 浏览 器 的 最 大 池 规 模 都 是 6 个 
套 接 字 。 
自动 化 的 套 接 字 池 管理 会 自动 重用 TCP 连接 ， 从 而 有 效 保障 性 能 (参见 11.1 节 
“持久 连接 的 优点 ”)。 除 此 之 外 ， 这 种 架构 设计 还 提供 了 其 他 优化 的 机 会 : 


可 以 按照 优先 次 序 发 送 排 队 的 请 求 ， 





. 六 lI 三 己 


| 


[vA 
。 浏览 器 可 以 重用 套 接 字 以 最 小 化 延迟 并 提升 吞吐 量 ， 


。 
。 浏览 器 可 以 优化 何 时 关闭 空闲 套 接 字 ， 
。 浏览 器 可 以 优化 分 配给 所 有 套 接 字 的 带宽 。 


简单 来 说 ， 浏 览 器 的 网 络 组 件 是 我 们 交付 高 性 能 应 用 的 同盟 。 刚 刚 介 绍 的 这 些 功能 ， 
没有 一 项 需要 我 们 参与 ! 但 这 并 不 是 说 我 们 不 能 再 帮助 浏览 器 。 我 们 的 设计 决策 对 
应 用 性 能 同样 起 着 至 关 重 要 的 作用 ， 因 为 这 些 决 策 会 影响 网 络 通信 的 模式 、 类 型 和 
传输 频率 ， 以 及 协议 选择 和 服务 器 端的 性 能 优化 。 


器 
年 辟 
| 览 器 可 以 预测 请 求 提 前 打开 套 接 字 ， 
乍 避 
策 器 





谷歌 Chrome 的 推测 性 网 络 优化 
我 们 已 经 知道 了 ， 现 代 浏览 器 的 网 络 组 件 并 非 一 个 套 接 字 管理 器 那么 简单 。 但 是 ， 
即使 如 此 有 时 候 也 足以 客观 地 评价 现代 浏览 器 中 的 某 些 优化 技术 。 


比如 ， 你 使 用 谷歌 Chrome 浏览 器 的 次 数 越 多 ， 它 的 速度 就 会 越 快 。Chrome 会 学 
习 访 问 过 的 站 点 的 拓扑 ， 以 及 常见 的 浏览 模式 ， 然 后 利用 这 些 信息 进行 各 种 “ 推 
测 性 优化 ， 以 预测 用 户 下 一 步 的 操作 ， 从 而 消除 不 必要 的 网 络 延 迟 : DNS 预 解 
析 、TCP 预 连接 、 页 面 预演 染 ， 等 等 。 像 鼠标 是 停 在 链接 上 这 么 个 简单 的 动作 ， 
就 可 以 触发 浏览 器 向 其 网 络 组 件 的 “预测 器 ”发 送信 号 ， 后 者 则 会 依据 过 往 的 性 
能 数据 选择 最 佳 的 优化 措施 。 

要 了 解 这 方面 更 多 信息 ， 请 参考 10.5 节 “ 针 对 浏览 器 的 优化 建议 ”。 如 果 你 对 
Chrome 浏览 器 的 网 络 优化 技术 感 兴趣 ， 可 以 看 看 这 篇 文章 “High Performance 
Networking in Google Chrome”: http://hpbn.co/chrome-networking, 
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14.2 网 络 安全 与 沙 箱 


ee 可 以 让 浏览 器 运用 


箱 机 制 ， 对 不 受信 任 的 应 用 代码 采取 一 致 的 安全 与 策略 限制 。 比 如 ， 浏 览 器 不 





ee es hd API， 因 为 这 样 给 恶意 应 用 向 任意 主机 发 起 任意 请 求 
(端口 扫描 、 连 接 邮件 服务 器 或 发 送 未 知 消息 ) 提供 可 乘 之 机 。 


连接 限制 
浏览 器 管理 所 有 打开 的 套 接 字 池 并 强制 施加 连接 数 限制 ， 保 护 客 户 端 和 服务 器 的 
资源 不 会 被 耗 尽 。 


请 求 格 式 化 与 响应 处 理 
人 致 和 符合 协议 的 语义 ， 从 而 保护 服务 
器 。 类 似 地 ， 响 应 解码 也 会 自动 完成 ， 以 保护 用 户 。 


TLS 协 识 
浏览 器 执行 TLS 握手 和 必要 的 证 书 检查 。 任 何 证 书 有 问题 (比如 服务 器 正在 使 用 
自己 签发 的 证 书 ) ， 用 户 都 会 收 到 通知 。 





同 源 策略 
浏览 器 会 限制 应 用 只 能 向 哪个 来 源 发 送 请 求 。 


以 上 列 出 的 安全 限制 机 制 只 是 一 部 分 ， 但 已 经 可 以 体现 “最 低 特权 ”(least 
privilege) 原则 了 。 浏 览 器 只 向 应 用 代码 2 公开 那些 必要 的 API 和 资源 ， 应 用 提供 数 
据 和 URL， 浏 览 器 执行 请 求 并 负责 管理 每 个 连接 的 整个 生命 周期 。 


' 碟 一 有 必要 提 一 句 ， 并 没有 单独 一 条 原则 叫 “ 同 源 策略 ”。 实 际 上 ， 这 是 一 组 相 
心 关 的 机 制 ， 涉 及 对 DOM 访问 、cookie 和 会 话 状 态 管理 、 网 络 及 其 他 浏览 
必 ， 器 组 件 的 限制 。 
要 全 面 解析 浏览 器 安全 ， 可 能 需要 另外 一 本 书 。 如 果 你 真 想 了 解 这 方面 
信息 ， 可 以 看 看 Michal Zalewski 的 The Tangled Web: 4 Guide to Securing 

Modern Web Applications’" 。 




















14.3 资源 与 客户 端 状态 缓存 


人 在 分 派 请 求 之 前 ， 浏 览 器 会 自动 检查 其 资源 缓存 ， 执 





行 必 要 的 验证 ， 然 后 在 满足 限制 条 件 的 情况 下 返回 资源 的 本 地 副本 。 类 似 地 ， 如 果 

















注 1: 中 文 版 《Web 之 困 : 现代 Web 应 用 安全 指南 》 由 机 械 工业 出 版 社 出 版 。 一 一 译 者 注 
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某 本 地 资源 不 在 缓存 中 ， 那 么 浏览 器 就 会 发 送 网 络 请 求 ， 将 响应 自动 填充 到 缓存 中 ， 
以 备 后 续 访问 使 用 。 


eA 自动 执行 缓存 指令 
能 恢复 失效 资源 的 有 效 性 ， 
ee 资源 回收 。 


高 效 、 最 优 地 管理 缓存 很 困难 。 所 幸 ， 浏 览 器 会 末 我 们 照管 这 一 切 ， 我 们 要 做 的 ， 
只 是 确保 服务 器 返回 适当 的 缓存 指令 (参见 13.1.1 节 “ 在 客户 端 缓存 资源 ”) 。 你 已 

经 让 服务 器 对 页 面 的 所 有 资源 都 返回 Cache-ControL、ETag 和 Last-Modified 等 啊 应 
首部 了 ， 对 不 ? 


最 后 ， 浏 览 器 还 有 一 个 经 常 被 人 忽视 的 重要 功能 ， 那 就 是 提供 会 话 认证 和 cookie 管 
理 。 浏 览 器 为 每 个 来 源 维护 着 独立 的 cookie 容器 ， 为 读 写 新 cookie、 会 话 和 认证 数 
据 提供 必要 的 应 用 及 服务 器 API， 还 会 为 我 们 自动 追加 和 处 理 HTTP 首部 ， 让 _ 切 
都 自动 化 。 


中 给 
内 





。 浏览 器 会 








举 一 个 简单 但 直观 的 例子 ， 它 能 说 明 把 会 话 状态 管理 委托 给 浏览 器 的 好 处 ， 
4 4 、 认 证 的 会 话 可 以 在 多 个 标签 页 或 浏览 器 口 间 共享 ， 反 之 亦 然 ， 如 果 用 户 在 
全 个 标 答 页 中 进出， 那么 其 他 所 有 打开 窗口 中 的 会 话 都 将 天 效 。 














14.4 ”应 用 AP 上 与 协议 


在 浏览 器 提供 的 网 络 服务 的 最 上 层 ， 就 是 应 用 API 和 协议 。 前 面 介 绍 了 下 层 提供 
ta 套 接 字 和 连接 管理 、 请 求 和 响应 处 理 、 各 种 安全 机 制 、 缓 存 ， 等 

。 我 们 每 次 发 起 HTTP 或 XMLHttpRequest 请 求 ， 或 者 长 Server-Sent Event 或 
WebSocket 会 话 ， 或 者 打开 WebRTC 连接 ， 都 需要 与 其 中 一 些 或 全 部 底层 服务 打 


交道 。 


不 存在 哪个 协议 或 API 最 好 的 问题 。 每 个 稍微 复杂 点 的 应 用 都 会 基于 不 同 的 需 
求 用 到 各 种 传输 机 制 ， 包 括 读 写 浏 览 器 缓存 、 协 议 开 销 、 消 息 延 人 运 、 可 靠 性 、 数 
据 传输 类 型 ， 等 等 。 某 些 协议 的 交付 延迟 可 能 短 一 些 〈 比 如 Server-Sent Events、 
WebSocket)， 但 却 不 能 满足 其 他 条 件 ， 比 如 利用 浏览 器 缓存 ， 或 者 在 所 有 场景 下 支 
持 高 效 的 二 进 制 传输 ( 表 14-1)。 
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表 14-1: XHR、SSE 和 WebSocket 的 高 级 特性 


























XMLHttpRequest Server-Sent Event WebSocket 
请 求 流 否 否 是 
响应 流 受 限 是 是 
分 帧 机 制 HTTP 事件 流 二 进 制 分 帧 
二 进 制 数据 传输 是 否 (base64) 是 
压缩 是 是 受 限 
应 用 传输 协议 HTTP HTTP WebSocket 
网 络 传输 协议 TCP TCP TCP 





硅 六 





我 们 在 这 个 表 中 有 意 忽略 了 WebRTC， 因 为 那 是 一 种 
已 4、 与 XHR、SSE 和 WebSocket 协议 有 着 根本 的 不 同 。 


0, 





端 到 端的 交付 模型 ， 


这 里 比较 的 高 级 特性 并 不 完整 (其 余 内 容 将 在 接 下 来 儿童 讨论 )， 但 也 足以 表明 每 种 
协议 之 间 的 大 量 差异 。 理 解 了 每 种 协议 的 长 处 和 短处 ， 根 据 应 用 的 需求 恰当 运用 它 


们 ， 就 可 以 摆脱 贫乏 的 用 户 体验 ， 打 造 出 高 性 能 应 用 。 
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第 15 章 
XMLHttpRequest 








XMLHttpRequest (XHR) 是 浏览 器 层面 的 API， 可 以 让 开发 人 员 通 过 JavaScript 
实现 数据 传输 。XHR 是 在 Internet Explorer 5 中 首次 亮相 的 ， 后 来 成 为 AJAX 
(Asynchronous JavaScript and XML) 革命 的 核心 技术 ， 是 今天 几乎 所 有 Web 应 用 
必 不 可 少 的 基本 构件 。 














XMLHTTP 改 交 了 一 切 。 它 让 DHTML 中 的 D 变 得 名 副 其 实 。 它 让 我 们 能 异 
步 从 服务 器 获取 数据 ， 同 时 在 客户 端 保 持 文档 状态 …… Outlook Web Access 
(OWA) 团队 希望 在 浏览 器 中 构建 一 个 类 似 Win32 应 用 的 想法 使 其 得 以 进入 
卫 ， 而 这 才 有 了 后 来 的 AJAX。 





Jim Van Eaton 

Outlook Web Access: A catalyst for web evolution 
XHR 诞生 前 ， 网 页 要 获取 客户 端 和 服务 器 的 任何 状态 更 新 ， 都 必须 刷新 一 次 。 有 了 
XHR， 这 个 过 程 就 可 以 异步 实现 ， 而 且 完 全 通过 应 用 的 JavaScript 代码 完成 。XHR 
是 让 我 们 从 制作 网 页 转换 为 开发 交互 应 用 的 根本 技术 。 


然而 ，XHR 的 能 力 不 仅 仅 表现 在 能 实现 浏览 器 的 异步 通信 ， 还 表现 在 它 极 大 地 简化 
了 这 个 异步 通信 过 程 。XHR 是 浏览 器 提供 的 应 用 API， 这 就 意味 着 浏览 器 会 自动 帮 
我 们 完成 所 有 底层 的 连接 管理 、 协 议 协 商 、HTTP 请 求 格式 化 ， 以 及 更 多 工作 : 


览 器 管理 着 连接 建立 、 套 接 字 池 和 连接 终止 ; 
览 器 决定 最 佳 的 HTTP (S) 传输 协议 (HTTP 1.0、1.x 和 ?2.0) 
览 器 处 理 HTTP 缓存 、 重 定向 和 内 容 类 型 协商 ; 
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。 浏览 器 保障 安全 、 验 证 和 隐私 ; 


不 用 关心 这 些 底层 细节 ， 那 么 我 们 就 可 以 把 时 间 和 精力 放 在 应 用 的 业务 逻辑 上 ， 只 
要 发 起 请 求 、 管 理 进度 ， 然 后 处 理 服务 器 返回 的 数据 即 可 。 简 单 的 API 加 上 所 有 浏 
览 器 的 支持 ， 使 得 XHR 成 为 了 浏览 器 网 络 开 发 中 的 “瑞士 军刀 ”。 


结果 ， 几 乎 所 有 网 络 应 用 (脚本 下 载 、 上 传 、 流 传输 ， 其 至 实时 通知 ) ， 都 能 够 或 者 
已 经 都 通过 XHR 实现 。 当 然 ， 这 并 不 是 说 XHR 在 任何 场景 中 都 是 最 有 效 的 传输 方 
式 (事实 上 ， 后 面 我 们 会 讨论 ， 多 数 情况 下 并 非 如 此 )， 但 无 论 如 何 它 都 经 常 被 作 
为 旧版 客户 端的 后 备 传输 方式 ， 这 些 旧 客户 端 通常 没有 实现 较 新 的 浏览 器 网 络 API。 
知道 了 这 一 点 ， 下 面 就 来 了 解 一 下 XHR 最 新 的 功能 ， 它 的 适用 场景 ， 以 及 我 们 在 
性 能 优化 方面 能 做 什么 和 不 能 做 什么 。 
































博信 

详尽 讨论 XHR API 超 出 了 我 们 的 范畴 ， 我 们 只 讨论 性 能 相关 的 话题 ! 请 
MA 4 参考 W3C 官方 对 XMLHttpRequest API 的 描述 ; http://www.w3.org/TR/ 
XMLHttpRequest/。 





15.1 XHR 简 史 


尽管 名 字 里 有 XML 的 X，XHR 也 不 是 专门 针对 XML 开发 的 。 这 只 是 因为 Internet 
Explorer 5 当初 发 布 它 的 时 候 ， 把 它 放 到 MSXML 库 里 ， 这 才 “ 继 承 ” 了 这 个 和 ， 





那 是 值得 纪念 的 日 子 ， 就 在 发 版 前 几 天 ， 又 增加 了 一 些 关键 的 功能 ……… 我 知 
道 MSXML 库 要 随 IE 一 起 发 布 ， 我 跟 XML 团队 关系 还 不 错 ， 觉 得 他 们 或 
许 能 帮 个 忙 。 我 找到 当时 的 团队 领导 Jean Paoli， 很 快 就 说 服 他 同意 把 它 作 
为 MSXML 库 的 一 部 分 发 布 。 它 其 实 主要 跟 HTTP 相关 , 跟 XML 基本 上 没 
什么 关系 ,仅仅 是 为 了 让 它 能 早点 发 布 ,我 才 硬 给 它 起 了 一 个 带 XML 的 名 字 。 





Alex Hopmann 

The story of XMLHTTP 
Mozilla 按照 微软 的 实现 也 实现 了 自己 的 XHR， 并 将 其 命名 为 XMLHttpRequest。 
Safari、Opera 和 其 他 浏览 器 也 紧 随 其 后 ， 于 是 XHR 成 为 了 所 有 主流 浏览 器 中 的 事 
实 标准 。W3C 针对 XHR 的 官方 工作 草案 发 布 于 2006 年 ， 而 这 已 经 是 XHR 得 到 广 
泛 应 用 以 后 的 事 了 ! 


虽然 它 在 AJAX 革命 中 扮演 了 至 关 重 要 的 角色 ， 但 XHR 的 早期 版 本 确实 能 力 有 限 : 
只 能 传输 文本 ， 处 理 上 传 的 能 力 不 足 ， 而 且 不 能 处 理 跨 域 请 求 。 为 解决 这 些 问 题 ， 
W3C 于 2008 年 发 布 了 “XMLHttpRequest Level 2” 草 案 ， 新 增 了 如 下 一 些 新 功能 : 
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。 支持 请 求 超时 ， 

。 支持 传输 二 进 制 和 文本 数据 ， 
0 
。 支持 监控 每 个 请 求 的 进度 事件 ， 

。 

。 支持 安全 的 跨 来 源 请 求 。 




















2011 年 , “XMLHttpRequest Level 2” 规 范 与 原来 的 XMLHttpRequest 工作 草案 
合并 。 此 后 ， 无 论 人 们 提 及 XHR 时 说 Level 1 还 是 Level 2， 其 实 已 经 没有 关系 
了 。 今天 ， 只 有 一 个 统一 的 XHR 规范 。 而 所 有 新 的 XHR2 功能 ， 都 是 通过 同一 个 
XMLHttpRequest API 提供 的 : 接口 不 变 ， 功 能 增强 。 


增 全 





新 XHR2 功能 目前 已 经 得 到 所 有 现代 浏览 器 支持 ， 参 见 : caniuse.com/ 
心 4 、xhr2。 此 后 ， | XHR， 指 的 都 是 XHR2 标准 。 


No 
人， 








15.2 ” 跨 源 资源 共享 (CORS ) 


XHR 是 一 个 浏览 器 层面 的 API， 向 我 们 隐藏 了 大 量 底层 处 理 ， 包 括 缓存 、 重 定向 、 
内 容 协商 、 认 证 ， 等 等 。 这 样 做 有 两 个 目的 。 第 一 ，XHR 的 API 因此 非常 简单 ， 开 
发 人 员 可 以 专注 业务 逻辑 。 其 次 ， 浏 览 器 可 以 采用 沙 箱 机 制 ， 对 应 用 代码 强制 施加 
一 套 安 全 限制 。 


XHR 接口 强制 要 求 每 个 请 求 都 严格 具备 HITP 语义 : 应 用 提供 数据 和 URL， 浏 览 
鲁 器 格 式 化 请 求 并 管理 每 个 连接 的 完整 生命 周期 。 类 似 地 ， 虽 然 XHR API 允许 应 用 添 
加 自 定义 的 HTTP 首部 (通过 setRequestHeader() 方法 )， 同 时 也 有 一 些 首部 是 应 用 
代码 不 能 设 定 的 : 





。 Accept-Charset、 Accept-Encoding、Access-Control-* 
。 Host、 Upgrade、Connection、Referer、Origin 
。 Cookie、Sec-*、Proxy-* 以 及 很 多 其 他 首部 

浏览 器 会 拒绝 对 不 安全 首部 的 重 写 ， 以 此 保证 应 用 不 能 假扮 用 户 代理 、 用 户 或 请 求 
来 源 。 事 实 上 ， 保 护 来 源 (Origin) 首部 特别 重要 ， 因 为 这 是 对 所 有 XHR 请 求 应 用 
“ 同 源 策略 ”的 关键 。 


5 
, 





一 个 “ 源 ” 由 应 用 协议 、 域 名 和 端口 这 三 个 要 件 共同 定义 。 比 如 ，(http， 
4 。 example.com, 80) 和 (https, example.com, 443) 就 是 不 同 的 源 。 更 多 信息 ， 请 参 
个， 考 “The Web Origin Concept” (http://tools.ietf.org/html/draft-abarth-origin ) 。 
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同 源 策 略 的 出 发 点 很 简单 : 浏览 器 存储 着 用 户 数据 ， 比 如 认证 令 牌 、cookie 及 其 
他 私有 元 数据 ， 这 些 数 据 不 能 泄露 给 其 他 应 用 。 如 果 没 有 同 源 沙 箱 ， 那 么 example. 
com 中 的 脚本 就 可 以 访问 并 操纵 thirdparty.com 的 用 户 数据 ! 


为 解决 这 个 问题 ，XHR 的 早期 版 本 都 限制 应 用 只 能 执行 同 源 请 求 ， 即 新 请 求 的 来 
源 必须 与 日 请 求 的 来 源 一 致 : 来 自 example.com 的 XHR 请 求 ， 只 能 从 example.com 
请 求 其 他 资源 。 如 果 后 续 请 求 不 同 源 ， 浏 览 器 就 拒绝 该 XHR 请 求 并 报错 。 


可 是 ， 在 某 些 必 要 的 情况 下 ， 同 源 策略 也 会 给 更 好 地 利用 XHR 带 来 麻烦 : 如 果 服 
务 器 想 要 给 另 一 个 网 站 中 的 脚本 提供 资源 怎么 办 ?这 就 是 Cross-Origin Resource 
Sharing ( 跨 源 资源 共享 ，CORS) 的 来 由 ! CORS 针对 客户 端的 跨 源 请 求 提供 了 安 
全 的 选择 同意 机 制 |: 














// 脚本 来 源 : (http，exampLe.com，80) 
var xhr = new XMLHttpRequest(); 
xhr.open('GET', '/resource.js'); © 


xhr.onload = function() { ... }; 
xhr.send(); 


var cors_xhr = new XMLHttpRequest(); 
cors_xhr.open('GET', 'http://thirdparty.com/resource.js'); © 


cors_xhr.onload = function() { ... }; 
cors_xhr.send(); 


@ 同 源 XHR 请 求 
四 跨 源 XHR 请 求 


CORS 请 求 也 使 用 相同 的 XHR API， 区 别 仅 在 于 请 求 资源 用 的 URL 与 当前 脚本 并 
不 同 源 。 在 前 面 的 例子 中 ， 当 前 执行 的 脚本 来 自 (http, example.com, 80)， 而 第 二 个 
XHR 请 求 访问 的 resource.js 则 来 自 (http, thirdparty.com, 80)。 





针对 CORS 请 求 的 选择 同意 认证 机 制 由 底层 处 理 : 请 求 发 出 后 ， 浏 览 器 自动 追加 受 保 
护 的 Origin HTTP 首部 ， 包 含 着 发 出 请 求 的 来 源 。 相 应 地 ， 远 程 服务 器 可 以 检查 Origin 
首部 ， 决 定 是 否 接受 该 请 求 ， 如 果 接 受 就 返回 Access-Control-Allow-Origin 响应 首部 : 








=> 请 求 

GET /resource.js HTTP/1.1 
Host: thirdparty.com 

Origin: http://example.con © 


<= 响应 
HTTP/1.1 200 OK 
Access-Control-Allow-Origin: http://example.con © 
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@ Origin 首部 由 浏览 器 自动 设置 
名 选择 同意 首部 由 服务 器 设置 


在 前 面 的 例子 中 ，thirdparty.com 决定 同意 与 example.com 跨 源 共享 资源 ， 因 此 就 在 
响应 中 返回 了 适当 的 访问 控制 首部 。 假 如 它 达 树 不 同意 接受 这 个 请 求 ， 那 么 只 要 不 
在 响应 中 包含 Access-Control-Allow-Origin 首部 即 可 。 这 样 ， 客 户 端 的 浏览 器 就 会 
自动 将 发 出 的 请 求 作废 。 





增 全 


如 果 第 三 方 服务 器 不 支持 CORS， 那 么 客户 端 请 求 同 样 会 作废 ， 因 为 客户 
a 

















s 端 会 验证 响应 中 是 否 包含 选择 同意 的 首部 。 作 为 一 个 特例 ，CORS 还 允许 
”服务 器 返回 一 个 通 配 值 (Access-ControL-ALLow-0rigin: *)， 表示 它 允许 
来 自任 何 源 的 请 求 。 不 过 ， 在 启用 这 个 选项 前 ， 请 大 家 务必 三 思 ! 





























这 就 是 全 部 了 吧 ? 准确 地 讲 ， 不 是 。 因 为 CORS 还 会 提前 采取 一 系列 安全 措施 ， 以 
确保 服务 器 支持 CORS : 


。 CORS 请 求 会 省 略 cookie 和 HTTP 认证 等 用 户 凭据 ， 
。 客户 端 被 限制 只 能 发 送 “ 简 单 的 跨 源 请 求 "， 包 括 只 能 使 用 特定 的 方法 (GET.、 
POST 和 HEAD)， 以 及 只 能 访问 可 以 通过 XHR 发 送 并 读 取 的 HTTP 首部 。 














要 启用 cookie 和 HTTP 认证 ， 客 户 端 必须 在 发 送 请 求 时 通过 XHR 对 象 发 送 额外 
的 属性 (withCredentials)， 而 服务 器 也 必须 以 适当 的 首部 (Access-Control-Allow- 
Credentials) 响应 , 表示 它 允 许 应 用 发 送 用 户 的 隐私 数据 。 类 似 地 ， 如 果 客 户 端 需要 
写 或 者 读 自 定义 的 HTTP 首部 ， 或 者 想 要 使 用 “不 简单 的 方法 ”发 送 请 求 ， 那 么 它 
必须 首先 要 获得 第 三 方 服务 器 的 许可 ， 即 向 第 三 方 服务 器 发 送 一 个 预备 (preflight) 
请 求 : 





=> 预备 请 求 

OPTIONS /resource.js HTTP/1.1 © 

Host: thirdparty.com 

Origin: http://example.com 
Access-Control-Request-Method: POST 
Access-Control-Request-Headers: My-Custom-Header 


<= 预备 响应 
HTTP/1.1 200 OK @ 


Access-Control-Allow-Origin: http://example.com 
Access-Control-Allow-Methods: GET, POST, PUT 
Access-Control-Allow-Headers: My-Custom-Header 


(正式 的 HTTP 请 求 ) @ 
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@ 验证 许可 的 预备 oPTIONS 请 求 
@ 第 三 方 源 的 成 功 预备 响应 
@ 实际 的 CORS 请 求 


W3C 官方 的 CORS 规范 规定 了 何 时 何 地 必须 使 用 预备 请 求 :“ 简 单 的 ”请 求 可 以 跳 

它 ， 但 很 多 条 件 下 这 个 请 求 都 是 必需 的 ， 因 此 也 会 为 验证 许可 而 增加 仅 有 一 次 往 
返 的 网 络 延迟 。 好 在 ， 只 要 完成 预备 请 求 ， 客 户 端 就 会 将 结果 缓存 起 来 ， 后 续 请 求 
就 不 必 重 复 验 证 了 。 








5 


CORS 得 到 了 所 有 现代 浏览 器 支持 ， 参 见 : caniuse.com/cors。 要 全 面 了 解 
人 心 4 ，CORS 的 各 种 策略 及 实现 ， 请 参考 W3C 官方 标准 (http:/www.w3.org/TR/ 


DS 
~ Cors/)。 





15.3 通过 XHR 下 载 数 据 
XHR 既 可 以 传输 文本 数据 ， 也 可 以 传输 二 进 制 数据 。 事 实 上 ， 浏 览 器 可 以 自动 为 各 


种 原生 数据 类 型 提供 编码 和 解码 服务 ， 因 此 应 用 在 直接 将 这 些 数据 传 给 XHR 时 就 
已 经 编码 / 解码 好 了 ， 反 之 亦 然 。 浏 览 器 可 以 自动 解码 的 数据 类 型 如 下 。 





。 ArrayBuffer 
固定 长 度 的 二 进 制 数据 缓冲 区 。 





。 Blob 
二 进 制 大 对 象 或 不 可 变数 据 。 


。 Document 


解析 后 得 到 的 HTML 或 XML 文档 。 





。 JSON 

表示 简单 数据 结构 的 JavaScript 对 象 。 
。 Text 

简单 的 文本 字符 串 。 
浏览 器 可 以 依靠 HTTP 的 content-type 首部 来 推断 适当 的 数据 类 型 (比如 把 
application/json 响应 解析 为 JSON 对 象 )， 应 用 也 可 以 在 发 起 XHR 请 求 时 显 式 重 
写 数 据 类 型 : 





var xhr = new XMLHttpRequest(); 
xhr.open('GET', '/images/photo.webp'); 
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xhr.responseType = 'blob'; © 


xhr.onload = function() { 
if (this.status == 200) { 
var img = document.createElement('img'); 
img.src = window.URL.createObjectURL(this.response); @ 


img.onload = function() { 
window.URL.revokeObjectURL(this. src); © 


} 
document .body.appendChild(img); 


} 
}; 


xhr.send(); 


@ 将 返回 数据 类 型 设置 为 Blob 
四 基于 返回 的 对 象 创建 唯一 的 对 象 URI 并 设置 为 图 片 的 源 
@ 图 片 加 载 完毕 后 立即 释放 对 象 


注意 ， 这 里 我 们 在 以 原生 格式 传输 一 张 图 片 ， 没 有 使 用 base64 编码 ， 也 没有 使 用 数 
据 URI， 而 是 在 页 面 中 添加 了 一 个 <img> 元 素 。 这 样 在 JavaScript 中 处 理 接收 到 的 
二 进 制 数据 不 会 产生 任何 网 络 传输 开销 和 编码 开销 ! XHR API 让 我 们 得 以 通过 
脚本 高 效 、 动 态 地 开发 应 用 ， 无 论 操作 什么 数据 类 型 都 没 问 题 ， 全 部 用 JavaScript 
搞定 ! 





























号 -一 这 里 的 二 进 制 大 对 象 接口 (Blob) 属于 HTML5 的 File API， 就 像 一 个 不 
a | 透明 的 引用 ， 可 以 指向 任何 数据 块 (二 进 制 或 文本 )。 这 个 对 象 本 身 没有 太 
多 功能 ， 只 能 查询 其 大 小 、MIME 类 型 ， 或 将 它 切 分 成 更 小 的 块 。 这 个 对 
象 存在 的 真正 目的 ， 是 作为 各 种 JavaScript API 之 间 的 一 种 高 效 的 互 操作 

机 制 。 





























15.4 ”通过 XHR 上 传 数据 


通过 XHR 上 传 任何 类 型 的 数据 都 很 简单 ， 而 且 高 效 。 事实 上 ， 上 传 不 同类 型 数据 
的 代码 都 一 样 ， 只 不 过 最 后 在 调用 XHR 请 求 对 象 的 send() 方法 时 ， 要 传 入 相应 的 
数据 对 象 。 剩 下 的 事 就 都 由 浏览 器 处 理 了 : 

var xhr = new XMLHttpRequest(); 

xhr .open('POST','/upload'); 


xhr.onload = function() { ... }; 
xhr.send("text string"); @ 


var formData = new FormData(); © 
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formData.append('id', 123456); 
formData.append('topic', 'performance'); 


var xhr = new XMLHttpRequest(); 
xhr.open('POST', '/upload'); 
xhr.onload = function() { ... }; 
xhr.send(fornData); © 


var xhr = new XMLHttpRequest(); 
xhr.open('POST', '/upload'); 

xhr.onload = function() { ... }; 

var uInt8Array = new Uint8Array([1, 2, 3]); @ 


xhr.send(uInt8Array.buffer); © 


@ 把 简单 的 文本 字符 串 上 传 到 服务 器 
@ 通过 FormData API 动态 创建 表单 数据 


© 
© 
© 





向 服务 器 上 传 muLtipart/form-data 对 象 
创建 无 符号 、8 字 节 整 型 的 有 类 型 数组 (ArrayBuffer ) 





向 服务 器 上 传 字 节 块 


XHR 对 象 的 send() 方法 可 以 接受 DOMString、Document、FormData、Blob、File 及 
ArrayBuffer 对 象 ， 并 自动 完成 相应 的 编码 ， 设 置 适 当 的 HITP 内 容 类 型 (content-type)， 
然后 再 分 派 请 求 。 需 要 发 送 二 进 制 BLob 或 上 传 用 户 提交 的 文件 ? 简单 ， 取 得 对 该 对 
象 的 引用 ， 传 给 XHR。 事 实 上 ， 多 写 几 行 代码 ， 还 可 以 把 大 文件 切 成 几 小 块 : 





var blob = ...; © 


Const BYTES_PER_CHUNK = 1024 * 1024; © 
const SIZE = blob.size; 


Var start = 0; 
var end = BYTES_PER_CHUNK; 


while(start < SIZE) { © 


var xhr = new XMLHttpRequest(); 
xhr.open('POST', '/upload'); 
xhr.onload = function() { ... }; 


xhr.setRequestHeader('Content-Range', start+'-'+end+'/'+SIZE); @ 
xhr.send(blob.slice(start, end)); © 


start = end; 
end = start + BYTES_PER_CHUNK; 


} 








@ 任意 数据 (二进制 或 文本 ) 的 二 进 制 对 象 
四 将 块 大 小 设置 为 1 MB 





@ 以 1 MB 为 步 长 提 代 数据 块 
告诉 服务 器 上 传 的 数据 范围 (开始 位 置 - 结束 位 置 / 总 大 小 ) 
@ 通过 XHR 上 传 1 MB 大 小 的 数据 片段 

















XHR 不 支持 请 求 流 ， 这 意味 着 在 调用 send() 时 必须 提供 完整 的 文件 。 不 过 ， 前 面 
的 例子 示范 了 一 个 简单 的 解决 方案 : 切 分 文件 ， 然 后 通过 多 个 XHR 请 求 分 段 上 传 。 
这 种 实现 方案 当然 不 能 末代 真正 的 请 求 流 API， 但 对 某 些 应 用 来 说 却 是 一 个 可 行 的 
方案 。 








。 时 ， 假 如 某 个 块 由 于 掉 线 而 上 传 失 败 ， 应 用 可 以 随后 只 重新 上 传 该 块 ， 而 


Ed 3 
人 切 分 大 文件 上 传 是 个 不 错 的 技巧 ， 适 合 连接 不 稳定 或 经 常 中 断 的 场景 。 此 
EA 
Ce 
心 ， 不 必 重 新 上 传 整个 大 文件 。 








15.5 监控 下 载 和 上 传 进度 


网 络 连 接 可 能 会 间歇 性 中 断 ， 而 延迟 和 带宽 也 高 度 不 稳定 。 因 此 ， 我 们 怎么 知道 
XHR 请 求 成 功 了 ， 超 时 了 ， 还 是 失败 了 ? XHR 对 象 提供 了 一 个 方便 的 API， 用 于 
监控 进度 事件 ( 表 15-1) ， 这 些 事件 代表 请 求 的 当前 状态 。 


表 15-1: XHR 的 进度 相关 事件 





























事件 类 型 说 明 触发 次 数 
Loadstart 传输 已 开始 一 次 

progress 正在 传输 零 或 多 次 
error 传输 出 错 零 或 多 次 
abort 传输 终止 零 或 多 次 
Load 传输 成 功 零 或 多 次 
Loadend 传输 完成 一 次 











每 个 XHR 请 求 开始 时 都 会 触发 Loadstart 事件 ， 而 结束 时 都 会 触发 Loadend 事件 。 
在 这 两 事件 之 间 ， 还 可 能 触发 一 或 多 个 其 他 事件 ， 表 示 传 输 状 态 。 因 此 ， 要 监控 进 
度 ， 可 以 在 XHR 对 象 上 广 册 一 系列 JavaScript 事件 监听 器 








var xhr = new XMLHttpRequest(); 
xhr.open('GET','/resource'); 
xhr.timeout = 5000; © 


xhr.addEventListener('load’', function() { ... })); @ 
xhr.addEventListener('error', function() { ... ;© 


var onProgressHandler = function(event) { 
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if(event .LengthComputabtLe) { 
var progress = (event.loaded / event.total) * 100; @ 


a 
} 


xhr .upload.addEventListener('progress', onProgressHandler); © 
xhr.addEventListener('progress', onProgressHandler); @ 
xhr.send(); 


@ 设置 请 求 的 超时 时 间 为 5000 ms (默认 无 超时 限制 ) 


@ 为 请 求 成 功 注册 回调 

@ 为 请 求 失 败 注册 回调 

@ 计算 传输 进度 

@ 为 上 传 进度 事件 注册 回调 





@ 为 下 载 进 度 事件 注册 回调 


无 论 load 和 error 中 的 哪 一 个 被 触发 了 ， 都 代表 XHR 传输 的 最 终 状 态 ， 而 
progress 事件 则 可 能 触发 任意 多 次 ， 这 就 为 监控 传输 状态 提供 了 便利 我 们 可 以 比 
较 loaded 与 total 属性 ， 估 算 传 输 完 成 的 数据 比例 。 


5 
, 





要 估算 传输 完成 的 数据 量 ， 服 务 器 必须 在 其 响应 中 提供 内 容 长 度 (Content- 
Length) 首部 。 而 对 于 分 块 数据 , 由 于 响应 的 总 长 度 未 知 , 因此 就 无 法 估计 
进度 了 。 
另外 ，XHR 请 求 默 认 没有 超时 限制 ， 这 意味 着 一 个 请 求 的 “进度 ”可 以 无 限 
长 。 作 为 最 佳 实践 ， 一 定 要 为 应 用 设置 合理 的 超时 时 间 ， 并 适当 处 理 错 误 。 
































15.6 通过 XHR 实 现 流 式 数 据 传输 


在 某 些 场 景 下 ， 应 用 可 能 需要 或 者 应 该 递增 地 流 式 处 理 数 据 。 比 如 ， 等 到 客户 端 数 
据 可 用 时 上 传 ， 或 者 一 边 从 服务 器 下 载 一 边 处 理 数据 。 可 惜 的 是 ， 尽 管 这 种 场景 很 
重要 ,但 时 至 今日 仍然 没有 一 种 简单 有 效 和 跨 浏 览 器 的 API 来 实现 XHR 流 


。 上 传 时 ，send 方法 只 接受 完整 的 载 符 ， 
。 response、responseText 和 responseXML 属性 也 不 是 为 流 设 计 的 。 


在 XHR 规范 中 ， 流 式 数 据 处 理 从 未 成 为 官方 正式 考虑 的 使 用 场景 。 于 是 ， 除 了 手 
工 把 要 上 传 的 数据 切 分 ， 再 利用 多 个 XHR 请 求 进 代 上 传 之 外 ， 没 有 其 他 API 可 以 
实现 客户 端 与 服务 器 间 的 流 式 数 据 传输 。 类 似 地 ， 虽 然 XHR2 规范 提供 了 读 取 服务 
器 部 分 响应 的 能 力 ， 但 实现 的 效率 却 很 低 ， 而 且 有 诸多 限制 。 这 一 点 确实 令 人 诅 霄 。 
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不 过 ， 也 不 要 彻底 不 抱 希 望 。 没 有 把 流 作为 XHR 的 第 一 类 场景 考虑 是 一 个 公认 的 
缺漏 ， 因 此 目前 正 有 人 在 积极 地 解决 这 个 问题 : 


Web 应 用 必须 有 能 力 获得 并 操作 各 种 形式 的 数据 ， 包 括 随 着 时 间 推 移 逐 渐 可 
用 的 一 系列 数据 。 本 规范 定义 了 流 的 基本 表示 法 、 流 触发 的 错误 ， 以 及 通过 
编程 方式 读 取 和 创建 流 的 方式 。 

一 一 W3C Streams API 


XHR 加 上 Streams API 可 以 让 浏览 器 支持 高 效 的 XHR 流 。 可 是 ，Streams API 目前 
还 处 于 研讨 阶段 ， 没 有 一 个 浏览 器 支持 它 。 因 此 ， 我 们 暂时 就 没有 别 的 办 法 了， 对 
吧 ? 咽 ， 也 不 完全 对 。 如 前 所 述 ， 通 过 XHR 实现 流 式 上 传 还 不 行 ， 通 过 XHR 实现 
流 式 下 载 却 得 到 了 浏览 器 有 限 的 支持 : 

















var xhr = new XMLHttpRequest(); 
xhr.open('GET', '/stream'); 
xhr.seenBytes = 0; 


xhr.onreadystatechange = function() { @ 


if(xhr.readyState > 2) { 
var newData = xhr.responseText.substr(xhr.seenBytes); © 


// 处 理 newData 


xhr. seenBytes = xhr.responseText.Length; © 


} 
}; 


xhr.send(); 


@ 预订 状态 和 进度 通知 
名 从 部 分 响应 中 提取 新 数据 
全 更 新 处 理 的 字 市 偏 移 量 


这 个 例子 在 多 数 现代 浏览 器 中 都 可 以 运行 ， 但 性 能 并 不 理想 。 另 外 ， 还 有 很 多 关于 
实现 的 问题 和 注意 事项 。 


。 我 们 是 手工 跟踪 看 到 的 字 节 的 偏 移 量 ， 然 后 再 手工 切 分 数据 : responseText 则 组 
冲 了 完整 的 响应 ! 对 于 少量 数据 传输 而 言 , 这 不 是 问题 。 但 如 果 下 载 的 数据 很 大 ， 
特别 是 在 内 存 十 分 有 限 的 设备 比如 手机 上 ， 这 就 是 问题 了 。 释 放 缓 冲 数据 的 唯一 
方式 就 是 完成 当前 请 求 ， 并 且 打 开 一 个 新 请 求 。 

。 部 分 响应 只 能 通过 读 取 responseText 属性 获取 , 因此 也 就 只 能 局 限于 文本 数据 了 。 
没有 办 法 部 分 读 取 二 进 制 数据 的 响应 。 
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。 读 取 完 部 分 数据 后 ， 我 们 必须 自己 标识 数据 的 界限 : 应 用 代码 必须 定义 自己 的 数 
据 格式 ， 然后 再 缓冲 并 解析 数据 流 ， 提取 出 相应 的 信息 。 

。 浏览 器 缓冲 收 到 数据 的 方式 也 不 相同 : 有 的 会 立即 释放 ， 而 有 的 只 缓冲 小 响应 ， 
对 较 大 的 响应 块 则 立即 释放 。 

。 浏览 器 允许 递增 读 取 的 数据 类 型 也 不 一 样 : 有 的 允许 text/htmL， 而 有 的 只 允许 


application/x-javascript。 








简 言 之 ， 目 前 基于 XHR 的 流 实 现 起 来 既 麻 烦 ， 效 率 又 低 。 更 精 糕 的 是 ， 由 于 缺 
乏 规 范 ， 浏 览 器 实现 一 家 一 个 样 。 结 论 就 是 ， 在 Streams API 规范 正式 推出 之 前 ， 
XHR 并 不 适合 用 来 实现 流 式 数 据 处 理 。 





硅 六 


全] 没有 必要 失望 ! 虽然 XHR 满足 不 了 我 们 的 要 求 ， 我 们 还 有 其 他 办 法 ， 而 
A 
MY MS 

















是 专门 为 流 式 数据 处 理 设计 的 :Server-Sent Events 提供 方便 的 流 APL， 
”用 于 从 服务 器 向 客户 端 发 送 文 本 数据 ， 而 WebSocket 则 提供 了 高 效 、 双 向 
的 流 机 制 ， 而 且 同 时 支持 二 进 制 和 文本 数据 。 

















专 有 API 和 对 XHR 流 的 扩展 


Firefox 和 Internet Explorer 都 提供 了 定制 的 “XHR 流 扩 展 ”: 


。 Firefox 支持 moz-chunked-text 和 moz-chunked-arraybuffer; 


。 JInternet Explorer 支持 ms-stream。 


通过 将 XHR 对 象 上 的 responseType 属性 设置 为 前 述 数据 类 型 ， 这 两 个 浏览 器 就 可 
以 不 缓冲 整个 响应 ， 同 时 允许 通过 XHR 对 象 递增 地 读 取 二 进 制 响应 。 遗 憾 的 是 ， 
Chrome、Opera 及 其 他 主流 浏览 器 还 没有 类 似 的 API。 因 此 ，XHR 流 对 于 跨 浏 览 器 
应 用 来 说 ,仍然 不 可 行 。 


15.7 ”实时 通知 与 交付 


XHR 提供 了 一 种 简单 有 效 的 客户 端 与 服务 器 同步 的 方式 : 必要 时 ， 客 户 端 可 以 向 服 
务 器 发 送 一 个 XHR 请 求 ， 以 更 新 服务 器 上 的 相应 数据 。 然 而 ， 实 现 同样 但 相反 的 
操作 却 要 困难 一 些 。 如 果 服 务 器 的 数据 更 新 了 ， 那 怎么 通知 客户 端 呢 ? 


HTTP 没有 提供 服务 器 向 客户 端 发 起 连接 的 方式 。 因 此 ， 为 实时 接收 通知 ， 客 户 端 
要 么 必须 轮 询 服务 器 ， 要 么 就 得 利用 流 式 传输 让 服务 器 推送 通知 。 如 前 所 述 ， 主 流 
浏览 器 对 XHR 流 的 支持 有 限 ， 那 我 们 就 只 能 使 用 XHR 轮 询 了 。 
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增 必 





“实时 ”对 不 同 的 应 用 有 不 同 的 含义 : 有 些 应 用 要 求 毫 秒 级 的 精确 度 ， 而 
心 。 有 些 应 用 可 能 只 要 几 分 钟 同步 一 次 就 够 了 。 要 确定 最 佳 的 传输 方式 ， 首 先 
全” 必须 明确 自己 应 用 的 延迟 和 性 能 目标 ! 











15.7.1 通过 XHR 实 现 轮 询 

从 服务 器 取得 更 新 的 一 个 最 简单 的 办 法 ， 就 是 客户 端 在 后 台 定 时 发 起 XHR 请 求 ， 
也 就 是 轮 询 (polling)。 如 果 服 务 器 有 新 数据 ， 返 回 新 数据 ， 否 则 返回 空 响应 。 

轮 询 实现 起 来 简单 ， 但 也 经 常 效率 很 低 。 其 中 关键 在 于 选择 轮 询 间 隔 : 长 轮 询 间 隔 
意味 着 延迟 交付 ， 而 短 轮 询 间 隔 会 导致 客户 端 与 服务 器 间 不 必要 的 流量 和 协议 开销 。 
下 面 看 一 个 简单 的 例子 : 





function checkUpdates(url) { 
var xhr = new XMLHttpRequest(); 
xhr.open('GET', url); 
xhr.onload = function() { ... }; © 


xhr.send(); 


} 


setInterval("checkUpdates('/updates'), 60000"); © 


@ 处 理 从 服务 器 收 到 的 更 新 
四 每 60 秒 发 送 一 个 XHR 请 求 


。 每 个 XHR 请 求 都 是 一 次 独立 的 HTTP 请 求 ， 平 均 算 下 来 ， 每 个 HTTP 会 带 有 大 
约 800 字 贡 的 请 求 /响应 首部 〈 不 算 HTTP cookie ) 。 

。 定时 检查 很 有 效 ， 前 提 是 数据 能 按时 到 达 。 可 惜 的 是 ， 按 时 到 达 只 是 例外 ， 而 非 
常规 情形 。 于 是 ， 定 时 轮 询 也 会 导致 服务 器 端 消 息 可 用 与 交付 给 客户 端 之 间 的 额 
外 延迟 。 

。 除非 考虑 周到 , 否则 轮 询 对 于 无 线 网 络 来 说 常常 会 变 成 性 能 杀手 (参见 8.2 节 “ 消 
除 周期 性 及 无 效 的 数据 传输 ”)。 唤 醒 无 线 电 模块 会 消耗 很 多 电量 | 


最 佳 的 轮 询 间隔 是 多 少 ? 没有 唯一 的 答案 。 轮 询 频 率 取决 于 应 用 的 需要 ， 而 且 始 终 
都 会 存在 关于 效率 和 消息 延迟 的 权衡 。 所 以 说 ， 轮 询 最 适合 间隔 时 间 长 ， 新 事件 到 
达 时 间 有 规律 ， 且 传输 数据 量 大 的 场景 。 这 个 组 合 可 以 抵消 多 余 的 HITP 开销 ， 并 
将 消息 交付 的 延迟 最 小 化 。 
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XHR 轮 询 的 性 能 建 模 


为 说 明 如 何 权衡 XHR 轮 询 的 延迟 与 开销 ， 我 们 可 以 拿 一 个 简单 的 邮件 应 用 作 例 
子 。 这 个 应 用 使 用 XHR 轮 询 检查 服务 器 上 的 新 邮件 。 实 现 步 又 如 下 : 


。 客户 痛 每 60s 发 送 一 次 XHR 检查 更 新 ; 

。 每 次 XHR 请 求 都 包含 客户 问 知 道 的 最 近 消 息 ID; 
。 服务 器 用 客户 竟 发 送 的 ID 查询 其 消息 列表 ; 

。 服务 器 响应 新 消息 列表 或 空 列表 (表示 没有 更 新 ) 。 


消息 的 平均 延迟 是 多 长 时 间 ? 
如 果 服 务 器 端 消息 恰好 在 客户 端 检 查 更 新 之 前 到 达 ， 那 么 延迟 时 间 最 短 ， 只 
有 客户 端 到 服务 器 的 网 络 延 迟 。 相 反 ， 同 一 条 新 消息 如 果 在 客户 庙 刚 刚 检 查 
更 新 之 后 才 到 达 ， 那 么 这 条 消息 就 要 等 到 下 次 检查 时 才能 发 送 (多 等 60 s) 。 
实际 上 ， 如 果 消息 是 随机 到 达 的 ， 那 么 每 条 消息 平均 要 在 服务 器 上 等 待 30 8 
才能 让 客户 端 检查 到 。 


轮 询 的 开销 有 多 大 ? 
HTTP 1.x 的 请 求 与 响应 会 增加 大 约 800 字 节 的 载荷 (参见 11.5 节 “ 度 量 和 
控制 协议 开销 ") 。 加 上 客户 端 登 录 ， 还 会 有 额外 的 认证 cookie 和 消息 ID， 假 
设 又 会 增加 50 字 节 。 那 么 ,返回 空 消息 列表 的 请 求 的 开销 为 850 字 节 ! 假设 
有 10 000 个 客户 篇， 全 部 以 60 s 为 间隔 向 服务 器 轮 询 : 


850 字 节 x 8 位 x10000 
60 S 





= 1.13 Mbit/s 


算 下 来 服务 器 每 秒 要 处 理 167 个 请 求 ， 每 个 客户 端 每 次 请 求 要 发 送 850 字 节 数 
据 ， 相 当 于 服务 器 始终 要 承担 1.13 Mbits 的 入 站 流量 | 而 且 ， 这 还 是 不 向 客户 
端 发 送 任何 新 消息 情况 下 的 一 个 固定 迷 举 。 
30 s 的 延迟 是 否 太 高 了 ? 那 就 缩短 间隔 ， 但 这 样 一 来 ， 就 会 导致 更 高 的 吞吐 量 和 
开销 。 同 样 还 是 10 000 个 客户 端 ， 如 果 轮 询 间 隔 缩 短 到 1 s， 就 会 导致 60 Mbit/s 
以 上 的 吞吐 量 ! 简单 来 说 ， 轮 询 间 隔 越 短 ， 代 价 越 大 。 











15.7.2 ”通过 XHR 实 现 长 轮 询 

定时 轮 询 的 一 个 大 问题 就 是 很 可 能 造成 大 量 没 必要 的 空 检 查 。 记 住 这 一 点 之 后 ， 让 
我 们 来 对 这 个 轮 询 过 程 做 一 改进 (图 15-1) : 在 没有 更 新 的 时 候 不 再 返回 空 响应 ， 
而 是 把 连接 保持 到 有 更 新 的 时 候 。 
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图 15-1: 轮 询 ( 左 ) 与 长 轮 询 ( 右 ) 的 迟延 


利用 长 时 间 保 留 的 HTTP 请 求 (“ 挂 起 的 GET”) 来 让 服务 器 向 浏览 器 推送 
心 。 数 据 的 技术 ， 经 常 被 称 作 Comet。 不 过 ， 有 时 候 也 有 人 用 其 他 名 字 称呼 这 
”种 技术 ， 比 如 “保留 AJAX”、“AJAX 推送 ”或 “HTTP 推送 ”。 
































通过 将 连接 一 直 保持 打开 到 有 更 新 〈 长 轮 询 ) ， 就 可 以 把 更 新 立即 从 服务 器 发 送 给 客 
户 端 。 这 样 ， 长 轮 询 就 解决 了 消息 交付 延迟 的 问题 ， 同 时 也 消灭 了 空 检查 ， 减 少 了 
XHR 请 求 次 数 和 轮 询 的 整体 开销 。 在 交付 更 新 后 ， 长 轮 询 请 求 完成 ， 然 后 客户 端 再 
发 送 下 一 次 长 轮 询 请 求 ， 等 待 下 一 次 更 新 : 
function checkUpdates(url) { 
var xhr = new XMLHttpRequest(); 


xhr.open('GET', url); 
xhr.onload = function() { © 


checkUpdates('/updates'); 外 


}; 
xhr.send(); 


checkUpdates('/updates'); © 


@ 处 理 更 新 并 打开 新 的 长 轮 询 XHR 
@ 发 送 长 轮 询 请 求 并 等 待 下 次 更 新 (如 此 不 停 循 环 ) 
@ 发 送 第 一 次 长 轮 询 XHR 请 求 


这 样 的 话 ， 是 不 是 可 以 说 长 轮 询 永 远 都 比 定时 轮 询 好 呢 ?” 除 非 更 新 到 达 频 率 已 知 且 
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国定 ， 否 则 长 轮 询 的 延迟 总 是 最 短 的 。 如 果 延 迟 是 一 个 重要 考虑 因素 ， 那 么 长 轮 询 
就 是 最 好 方案 。 


从 另 一 方面 看 ， 还 需要 更 仔细 地 分 析 一 下 开销 。 首 先 ， 每 次 更 新 都 会 伴 有 相同 的 
HTTP 开销 ， 即 每 次 更 新 都 需要 一 次 独立 的 HTTP 请求。 如果 更 新 频率 很 高 ， 那 么 
长 轮 询 又 会 导致 比 定时 轮 询 更 多 的 XHR 请 求 ! 


长 轮 询 通过 最 小 化 延迟 可 以 动态 适应 更 新 频率 ， 这 种 行为 可 能 是 也 可 能 不 是 我 们 所 
期 望 的 。 如 果 应 用 可 以 容许 一 定时 间 的 延迟 ， 那 么 定时 轮 询 可 角 es 
新 频率 很 高 的 情况 下 ， 定 时 轮 询 就 是 一 个 简单 的 “更 新 累积 ”机 制 ， 能 减少 请 
求 次 数 ， 还 能 减少 对 手机 电量 的 消耗 。 





地 


实践 中 ， 并 不 是 所 有 更 新 都 具有 相同 的 优先 级 或 者 延迟 要 求 。 因 此 ， 你 可 
人 Q 4 、 以 考虑 采取 混合 策略 :在 服务 器 上 累积 低 优先 级 的 更 新 ， 同 时 对 高 优先 级 
发 ， 消息 则 立即 触发 更 新 (参见 8.2 节 的 “内 格 尔 及 有 效 的 服务 器 推送 ”)。 























Facebook 的 Chat 使 用 了 XHR 长 轮 询 


实际 应 用 中 ， 长 轮 询 已 经 成 为 通过 XHR 交付 实时 通知 的 一 个 使 用 最 广泛 的 方法 。 
虽然 这 种 方法 不 一 定 最 有 效 ， 但 它 简 单 、 可 靠 ， 在 任何 支持 XHR 的 浏览 器 中 通 
用 。Facebook 流行 的 Chat 应 用 就 在 2008 年 率先 采用 了 这 个 简单 的 方法 : 


为 了 让 一 个 用 户 从 另 一 个 用 户 那 里 取得 消息 ， 我 们 采用 了 这 个 方法 : 在 
每 个 Facebook 页 面 中 加 载 一 个 iframe， 让 这 个 iframe 中 的 JavaScript 发 
送 一 个 HTTP GET 请 求 ， 并 保持 连接 打开 ， 直 到 服务 器 把 数据 返回 客户 
端 再 关闭 连接 。 如 果 连 接 中 断 或 超时 ， 则 重新 建立 连接 。 这 个 方法 并 没 
有 使 用 任何 新 技术 ， 它 只 是 Comet (尤其 是 XHR 长 轮 询 ) 及 BOSH 的 
一 种 新 用 法 。 





Facebook Chat 
Facebook Engineering Blog 


今天 ， 通 过 Server-Sent Events 和 WebSocket 可 以 更 有 效 地 实现 同样 的 功能 。 即 使 


XHR 仍然 是 很 多 实时 通信 框架 的 常用 备 选 方案 。 如 果 所 有 技术 部 不 能 用 ， 
么 只 有 让 长 轮 询 顶 上 了 | 











15.8 XHR 使 用 场景 及 性 能 


XMLHttpRequest 是 我 们 从 在 浏览 器 中 做 网 页 Web 应 用 的 关键 。 首 先 ， 它 
让 我 们 在 浏览 器 中 实现 了 异步 通信 ， 但 同样 重要 的 是 ， 它 还 把 这 个 过 程 变 得 非常 简 
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单 。 分 派 和 控制 HTTP 请 求 只 要 几 行 JavaScript 代码 ， 而 其 他 复杂 的 任务 浏览 器 都 
包办 了 : 


览 器 格式 化 HTTP 请 求 并 解析 响应 ， 
览 器 强制 施加 相关 的 安全 ( 同 源 ) 策略 ; 
览 器 处 理 内 容 协 商 (如 gzip 压缩 ) ; 

览 器 处 理 请 求 和 响应 的 缓存 ; 

览 器 处 理 认证 、 重 定向 :…… 


Es 
i 省 


正 因为 如 此 ，XHR 成 了 所 有 使 用 HTTP 请 求 /响应 模式 来 传输 数据 的 一 种 全 能 又 
性 能 的 机 制 。 想 取得 需要 认证 的 资源 ， 且 传输 期 间 需 要 压缩 ， 取得 后 项 要 组 在 以 各 
后 用 ? 浏览 器 会 替 我 们 完成 这 一 切 ， 以 及 更 多 。 作 为 开发 者 ， 我 们 只 要 关注 自己 应 
用 的 逻辑 即 可 | 


不 过 ，XHR 也 有 其 自身 的 局 限 性 。 如 前 所 述 ，XHR 标准 从 未 考虑 流 式 数 据 处 理 的 
场景 ， 对 它 的 支持 也 有 限 。 这 就 造成 了 通过 XHR 进行 流 式 数据 传输 既 低 效 ， 又 不 
方便 。 不 同 的 浏览 器 还 有 不 同 的 行为 ， 有 效 的 二 进 制 流 式 传输 是 不 可 能 的 。 简 言 之 ， 
XHR 不 适合 流 式 数 据 处 理 。 


类 似 地 ， 也 没有 最 好 的 方式 通过 XHR 实时 交付 更 新 。 定 时 轮 询 会 导致 高 开销 及 
更 新 延迟 。 长 轮 询 的 延迟 低 ， 但 每 次 更 新 仍然 有 开销 ， 因 为 每 次 更 新 都 需要 一 次 
HTTP 请 求 。 既 想 低 延迟 ， 又 想 低 开 销 ， 除 非 你 有 XHR 流 ! 


于 是 ， 尽 管 XHR 是 一 种 “实时 ”交付 的 流行 机 制 ， 但 从 性 能 角度 说 ， 它 或 许 并 不 
是 最 佳 选择 。 现 代 浏 览 嚣 支持 比 它 更 简单 也 更 高 效 的 API， 比 如 Server-Sent Events 
和 WebSocket。 事 实 上 ， 除 非 你 有 特别 的 理由 要 使 用 XHR 轮 询 ， 否 则 应 该 使 用 这 
些 新 技术 。 
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服务 器 发 送 事件 





Server-Sent Events (SSE) 让 服务 器 可 以 向 客户 端 流 式 发 送 文本 消息 ， 比 如 服务 器 
上 生成 的 实时 通知 或 更 新 。 为 达到 这 个 目标 ，SSE 设计 了 两 个 组 件 : 浏览 器 中 的 
EventSource 和 新 的 “事件 流 ” 数 据 格式 。 其 中 ，EventSource 可 以 让 客户 端 以 DOM 
事件 的 形式 接收 到 服务 器 推送 的 通知 ， 而 新 数据 格式 则 用 于 交付 每 一 次 更 新 。 


EventSource API 和 定义 完善 的 事件 流 数据 格式 ， 使 得 SSE 成 为 了 在 浏览 器 中 处 理 实 
时 数据 的 高 效 而 不 可 或 缺 的 工具 : 


。 通过 一 个 长 连接 低 延 迟 交 付 ，; 

。 高 效 的 浏览 器 消息 解析 ， 不 会 出 现 无 限 缓冲 ， 
。 自动 跟踪 最 后 看 到 的 消息 及 自动 重新 连接 ， 
。 消息 通知 在 客户 端 以 DOM 事件 形式 呈现 。 



























































实际 上 ，SSE 提供 的 是 一 个 高 效 、 跨 浏览 器 的 XHR 流 实现 ， 消 息 交 付 只 使 用 一 个 
长 HTTP 连接 。 然 而 ， 与 我 们 自己 实现 XHR 流 不 同 ， 浏 览 器 会 帮 有 我 们 管理 连接 、 
解析 消息 ， 从 而 让 我 们 只 关注 业务 逻辑 。 一 句 话 ，SSE 让 处 理 实时 数据 变 得 简单 高 
效 ! 接 下 来 我 们 就 揭 开 它 神 秘 的 面纱 一 探究 竟 。 








16.1 EventSource API 


EventSource 接口 通过 一 个 简单 的 浏览 器 API 隐藏 了 所 有 的 底层 细节 ， 包 括 建立 连接 
和 解析 消息 。 要 使 用 它 ， 只 需 指 定 SSE 事件 流 资源 的 URL， 并 在 该 对 象 上 注册 相应 
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的 JavaScript 事件 监听 器 即 可 : 


var source = new EventSource("/path/to/stream-urL"); © 


source.onopen = function (){...};@© 


source.onerror = function (){...};®© 


source.addEventListener("foo", function (event) { @@ 


processFoo(event.data); 


1 


source.onmessage = function (event) { © 


log_message(event.id, event.data); 


if (event.id== "CLOSE") { 


} 
} 


source.close(); 


O 


@ 打开 到 流 终 点 的 SSE 连接 


@ 可 选 的 
全 可 选 的 





回调 ， 建 立 连 接 时 调用 
回调 ， 连 接 失 败 时 调用 


@ 监听 "foo" 事件 ， 调 用 自 定义 代码 
@ 监听 所 有 事件 ， 不 明确 指定 事件 类 型 
@ 如 果 服 务 器 发 送 "CLosE" 消息 ID ， 关 闭 SSE 连接 


培 。， 


全 
te 





EventSource 可 以 像 常 规 XHR 一 样 利 用 CORS 许可 及 选择 同意 机 制 ， 


。 现 客户 端 到 远程 服务 器 的 流 式 事件 数据 传输 。 


人 





这 就 是 客户 端 API 的 全 部 。 浏 览 器 会 帮 我 们 处 理 一 切 : 
并 递增 地 解析 数据 ， 标 识 消息 的 范围 ， 最 终 触 发 DOM 事件 。Eventsource 接口 的 设 
计 就 是 让 开发 者 只 关注 业务 逻辑 : 打开 新 连接 、 处 理 接 收 到 的 事件 通知 ， 然 后 在 完 


事 儿 时 终止 流 。 
Ee 
SSE 实现 了 
CA 
te 
































替 我 们 协商 建立 连接 ， 接 收 





节省 内 存 的 XHR 流 。 与 原始 的 XHR 流 在 连接 关闭 前 会 缓冲 接 


。 收 到 的 所 有 响应 不 同 ，SSE 连接 会 丢弃 已 经 处 理 过 的 消息 ， 而 不 会 在 内 存 


心中 累积 。 








值得 一 提 的 是 ，EventSource 接口 还 能 自动 重新 连接 并 跟踪 最 近 接 收 的 消息 : 如 果 连 
接 断 开 了 ，EventSource 会 自动 重新 连接 到 服务 器 ， 还 可 
到 的 消息 ID， 以 便服 务 器 重 传 丢 失 的 消息 并 恢复 流 。 





以 辣 服务 器 发 送 上 一 次 接收 
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浏览 器 怎么 知道 每 个 消息 的 ID 、 类 型 和 范围 呢 ? 这 里 就 用 到 了 事件 流 协议 。 我 们 之 
所 以 可 以 把 繁重 的 工作 托付 给 浏览 器 ， 就 是 因为 这 个 简单 的 客户 端 API 和 定义 完善 
的 数据 格式 。 这 两 个 组 件 总 是 密切 协同 ， 使 得 浏览 器 中 的 应 用 完全 不 必 理 会 底层 数 
据 协议 。 














使 用 自 编 JavaScript 模拟 EventSource 


SSE 最 初 是 HIMLS5 规范 的 补充 ， 得 到 了 大 多 数 现 代 浏 览 器 的 原生 支持 。 到 本 书 
翻译 时 为 止 ， 只 有 于 和 Opera Mini 不 支持 它 。 最 新 状态 请 参考 这 里 : caniuse. 
com/eventsource, 


不 过 ， 好 在 EventSource 接口 真 的 很 简单 ， 甚 至 者 可 以 在 不 支持 它 的 浏览 器 中 使 用 
JavaScript 库 (比如 某 个 “腻子 脚本 ”) 来 模拟 它 。 类 似 地 ， 事 件 流 的 交付 则 可 以 
在 现 有 的 XHR 机 制 基础 上 实现 : 

if (!window.EventSource) { 


// 加 载 Javascript 腻子 脚本 
} 


var source = new EventSource("/event-stream-endpoint"); 


使 用 腻子 脚本 的 好 处 ,仍然 是 让 我 们 只 关注 应 用 逻辑 ， 而 不 是 因 浏 览 器 支持 情况 
阅 心 。 话 虽 如 此 ， 腻 子 脚本 只 是 提供 了 一 致 的 API， 底 层 的 XHR 传输 机 制 依旧 不 
那么 高 效 : 

。 XHR 轮 询 会 导致 消息 延迟 和 很 高 的 请 求 开 销 ; 

。 XHR 长 轮 询 能 最 小 化 延迟 ， 但 开销 还 是 很 高 ; 

。 XHR 对 流 的 支持 有 限 ， 且 在 内 存 中 缓冲 所 有 数据 。 

在 对 高 效 XHR 流 没有 原生 支持 的 时 候 ， 腻 子 脚本 可 以 用 轮 询 、 长 轮 询 或 XHR 流 代 
替 ， 这 几 种 方案 各 有 利 产 。 要 了 解 详 细 人 信息， 请 参考 15.7 节 “ 实 时 通知 与 交付 ”。 
简单 来 讲 ， 你 得 自己 检查 一 下 选择 的 腻子 脚本 ， 保 证 它 能 达到 你 的 性 能 要 求 。 很 
多 流行 的 库 (比如 jQuery.EventSource) 都 使 用 XHR 轮 询 模拟 SSE， 为 我 们 提供 
了 简单 却 不 那么 高 效 的 选择 。 











16.2 ” Event Stream 协议 

SSE 事件 流 是 以 流 式 HTTP 响应 形式 交付 的 : 客户 端 发 起 常规 HTTP 请 求 ， 服 务 器 
以 自 定义 的 “text/event-stream” 内 容 类 型 响应 ， 然 后 交付 UTF-8 编码 的 事件 数据 。 
这 么 简单 几 句 话 似乎 都 有 点 说 复杂 了 ， 看 一 个 例子 
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=> 请 求 
GET /stream HTTP/1.1 © 


Host: example.com 
Accept: text/event-stream 


<= 响应 
HTTP/1.1 200 OK @ 


Connection: keep-alive 
Content-Type: text/event-stream 
Transfer-Encoding: chunked 


retry: 15000 © 
data: First message is a simple string. @ 
data: {f"message": "JSON payload"} © 


event: foo @ 

data: Message of type "foo" 
id: 42 包 

event: bar 


data: Multi-line message of 
data: type "bar" and id "42" 


id: 43 @ 
data: Last message, id "43" 
@ 客户 端 通过 EventSsource 接口 发 起 连接 
@ 服务 器 以 "text/event-stream" 内 容 类 型 响应 
@ 服务 器 设置 连接 中 断后 重新 连接 的 间隔 时 间 (15 s) 
@@ 不 带 消 息 类 型 的 简单 文本 事件 
加 不 带 消息 类 型 的 JSON 数据 载荷 
@@ 类 型 为 "foo" 的 简单 文本 事件 
@ 带 消息 ID 和 类 型 的 多 行事 件 
@ 带 可 选 ID 的 简单 文本 事件 


以 上 事件 流 协议 很 好 理解 ， 也 很 好 实现 : 


。 事件 载荷 就 是 一 或 多 个 相 邻 data 字段 的 值 ; 
。 事件 可 以 带 ID 和 event 表示 事件 类 型 ; 
。 事件 边界 用 换行 符 标识 。 


在 接收 端 ，EventSource 接口 通过 检查 换行 分 隔 符 来 解析 到 来 的 数据 流 ， 从 data 字 
























































段 中 提取 有 效 载 荷 ， 检 查 可 选 的 ID 和 类 型 ， 最 后 再 分 派 一 个 DOM 事件 告知 应 用 。 
如 果 存 在 某 个 类 型 ， 那 么 就 会 触发 自 定 义 的 DOM 事件 处 理 程序 ， 否则 ， 就 会 调用 
通用 的 onmessage 回调 ， 参 见 16.1 节 “EventSource API 。 





























SSE 中 的 UTF-8 编码 与 二 进 制 传输 


EventSource 不 会 对 实际 载荷 进行 任何 额外 处 理 : 从 一 或 多 个 data 字段 中 提取 出 
来 的 消息 ， 会 被 拼接 起 来 直接 交 给 应 用 。 因 此 ， 服 务 器 可 以 推送 任何 文本 格式 
(例如 ， 简 单字 符 串 、JSON， 等 等 ) ， 应 用 必须 自己 解码 。 


话 虽 如 此 ， 但 所 有 事件 源 数据 都 是 UTF-8 编码 的 : SSE 不 是 为 传输 二 进 制 载荷 而 
设计 的 | 如 果 有 必要 ， 可 以 把 二 进 制 对 象 编码 为 base64 有 形式， 然后 再 使 用 SSE。 
但 这 样 会 导致 很 高 (33%) 的 字 节 开销 ， 参 见 11.7 节 “ 谋 入 资源 ”。 


担心 UTF-8 编码 也 会 造成 高 开销 ? SSE 连接 本 质 上 是 HTTP 流 式 响应 ， 因 此 响 
应 是 可 以 压缩 的 (如 gzip 压缩 )， 就 跟 压 缩 其 他 HITP 响应 一 样 ， 而 且 是 动态 压 
缩 ! 虽然 SSE 不 是 为 传输 二 进 制 数据 而 设计 的 ， 但 它 却 是 一 个 高 效 的 机 制 只 
要 让 你 的 服务 器 对 SSE 流 应 用 gzip 压缩 。 

不 支持 二 进 制 传输 是 有 意 为 之 的 。SSE 的 设计 目标 是 简单 、 高 效 ， 作 为 一 种 服务 
器 向 客户 端 传送 文本 数据 的 机 制 。 如 果 你 想 传输 二 进 制 数 据 ，WebSocket 才 是 更 
合适 的 选择 。 














最 后 ， 除 了 自动 解析 事件 数据 ，SSE 还 内 置 支持 断 线 重 连 ， 以 及 恢复 客户 端 因 断 线 
而 丢失 的 消息 。 默 认 情 况 下 ， 如 果 连 接 中 断 ， 浏 览 器 会 自动 重新 连接 。SSE 规范 建 
议 的 间隔 时 间 是 2~3 s， 这 也 是 大 多 数 浏 览 器 采用 的 默认 值 。 不 过 ， 服 务 器 也 可 以 
设置 一 个 自 定 义 的 间隔 时 间 ， 只 要 在 推送 任何 消息 时 向 客户 端 发 送 一 个 retry 命令 
即 可 。 

类 似 地 ， 服 务 器 还 可 以 给 每 条 消息 关联 任意 ID 字符 串 。 浏 览 器 会 自动 记录 最 后 一 
次 收 到 的 消息 ID， 并 在 发 送 重 连 请 求 时 自动 在 HITP 首部 追加 “Last-Event-ID” 
值 。 下 面 看 一 个 例子 : 


( 既 有 SSE 连接 ) 
retry: 4500 0 











id: 43 四 
data: Lorem ipsum 


连接 断 开 ) 
(4500 ms 后 ) 


=> 请 求 


一 、 
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GET /stream HTTP/1.1 © 


Host: example.com 
Accept: text/event-stream 
Last-Event-ID: 43 


<= 响应 
HTTP/1.1 200 OK @ 


Content-Type: text/event-stream 
Connection: keep-alive 
Transfer-Encoding: chunked 


id: 4 日 
data: dolor sit amet 
@ 服务 器 将 客户 端的 重 连 间隔 设置 为 4.5s 
@ 简单 文本 事件 ，ID:43 
图 带 最 后 一 次 事件 ID 的 客户 端 重 连 请 求 
@ 服务 器 以 'text/event-stream' 内 容 类 型 啊 应 
@ 简单 文本 事件 ，ID:44 


客户 端 应 用 不 必 为 重新 连接 和 记录 上 一 次 事件 ID 编写 任何 代码 。 这 些 都 由 浏览 器 
自动 完成 ， 然 后 就 是 服务 器 负责 恢复 了 。 值 得 注意 的 是 ， 根 据 应 用 的 要 求 和 数据 流 ， 
服务 器 可 以 采取 不 同 的 实现 策略 。 


。 如 果 丢 失 消 息 可 以 接受 ， 就 不 需要 事件 ID 或 特殊 逻辑 ， 只 要 让 客户 端 重 连 并 恢 
复数 据 流 妈 可。 

。 如 果 必 须 恢复 消息 ， 那 服务 器 就 需要 指定 相关 事件 的 ID， 以 便 客 户 端 在 重 连 时 报 
告 最 后 接收 到 的 ID。 同样 ， 服 务 器 也 需要 实现 某 种 形式 的 本 地 缓存 ， 以 便 恢 复 并 
向 客户 端 重 传 错过 的 消息 。 


当然 ， 像 要 保留 多 少 条 消息 这 种 细节 一 定 取决 于 具体 的 应 用 。 另 外 ， 要 知道 ID 是 
可 选 的 事件 流 字段 。 而 服务 器 也 可 以 在 交付 的 事件 流 中 对 特定 消息 设置 检查 点 或 者 
里 程 碑 标 记 。 一 句 话 ， 根 据 你 的 需求 ， 实 现 服务 器 逻辑 。 


16.3 SSE 使 用 场景 及 性 能 


SSE 是 服务 器 向 客户 端 发 送 实 时 文本 消息 的 高 性 能 机 制 : 服务 器 可 以 在 消息 刚刚 生 
成 就 将 其 推送 到 客户 端 ( 低 延迟 )， 使 用 长 连接 的 事件 流 协议 ， 而 且 可 以 gzip 压缩 
( 低 开 销 )， 浏 览 器 负责 解析 消息 ， 也 没有 无 限 缓冲 。 再 加 上 超级 简单 的 EventSource 
API 能 自动 重新 连接 和 把 消息 通知 作为 DOM 事件 ， 使 得 SSE 成 为 处 理 实时 数据 不 
可 或 缺 的 得 力 工具 ! 
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SSE 主要 有 两 个 局 限 。 一 ， 只 能 从 服务 器 向 客户 端 发 送 数 据 ， 不 能 满足 需要 请 求 流 
的 场景 (比如 向 服务 器 流 式 上 传 大 文件 ) ， 二 ， 事 件 流 协议 设计 为 只 能 传输 UTF-8 
数据 ， 即 使 可 以 传输 二 进 制 流 ， 效 率 也 不 高 。 


话 虽 如 此 ，UTF-8 的 限制 往往 可 以 在 应 用 层 克 服 : SSE 可 以 通知 应 用 说 服务 器 上 有 
一 个 新 的 二 进 制 文件 可 以 下 载 了 ， 应 用 只 要 再 分 派 一 个 XHR 请 求 去 下 载 即 可 。 虽 
然 这 样 多 了 一 次 往返 延迟 ， 但 也 能 利用 上 XHR 提供 的 诸多 便利 : 响应 缓存 、 传 输 
编码 (压缩)， 等 等 。 如 果 文 件 是 流 式 下 载 的 ， 那 它 就 无 法 被 浏览 器 缓存 。 








实时 推送 就 像 轮 询 一 样 ， 可 能 会 极 大 影响 电池 的 待机 时 间 。 首 先 ， 可 以 考 

4 4 ， 虐 批量 处 理 消 息 ， 尽 量 少 唤 醒 无 线 电 模块 。 其 次 ， 避 免 不 必 要 的 长 连接 ， 

GSE 连接 在 无 线 电 空闲 时 不 会 断 开 。 更 多 信息 ， 请 参考 8.2 节 “ 消 除 周 期 
性 及 无 效 的 数据 传输 ”。 



































通过 TLS 实现 SSE 流 
SSE 通过 常规 HTTP 连接 实现 了 简单 便捷 的 实时 传输 机 制 ， 服 务 器 端 容易 部 署 ， 
客户 问 也 容易 打 补 丁 。 可 是 ， 现 有 网 络 中 间 设 备 ， 比 如 代理 服务 器 和 防火 墙 ， 都 
不 支持 SSE， 而 这 有 可 能 带 来 问题 : 中 间 设 备 可 能 会 缓冲 事件 流 数据 ， 导 致 领 外 
， 甚 至 彻底 毁 掉 SSE 连接 。 


如 果 你 磁 到 了 这 样 3 或 类 似 的 问题 ， 那 么 可 以 考虑 通过 TLS 发 送 SSE 事件 流 ， 具 体 
请 参考 4.1 节 中 的 “Web 代理 、 中 间 设 备 、TLS 与 新 协议 ”。 
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WebSocket 





Websocket 可 以 实现 客户 端 与 服务 器 间 双 向 、 基 于 消息 的 文本 或 二 进 制 数据 传输 。 它 
是 浏览 器 中 最 靠近 套 接 字 的 API。 但 websocket 连接 远 远 不 是 一 个 网 络 套 接 字 ， 因 为 
浏览 器 在 这 个 简单 的 API 之 后 隐藏 了 所 有 的 复杂 性 ， 而 且 还 提供 了 更 多 服务 : 


。 连接 协商 和 同 产 策略 ; 

。 与 既 有 HTTP 基础 设施 的 互 操作 ，; 
。 基于 消息 的 通信 和 高 效 消息 分 帧 ; 
。 子 协议 协商 及 可 扩展 能 


WebSocket 是 浏览 器 中 最 通用 最 灵活 的 一 个 传输 机 制 ， 其 极 简 的 API 可 以 让 我 们 在 客 
户 端 和 服务 器 之 间 以 数据 流 的 形式 实现 各 种 应 用 数据 交换 (包括 JSON 及 自 定义 的 
二 进 制 消息 格式 )， 而 且 两 端 都 可 以 随时 向 另 一 端 发 送 数 据 。 


不 过 ， 自 定义 数据 交换 协议 的 问题 通常 也 在 于 自 定义 。 因 为 应 用 必须 考虑 状态 管理 、 
压缩 、 缓 存 及 其 他 原来 由 浏览 器 提供 的 服务 。 设 计 限 制 和 性 能 权衡 始终 会 有 ， 利 用 
Nebsocket 也 不 例外 。 简 单 来 说 ，websocket 并 不 能 取代 HTTP、XHR 或 SSE， 而 为 
了 追求 最 佳 性 能 ， 关 键 还 是 要 利用 这 些 机 制 的 长 处 。 


























a 


WebSocket 由 多 个 标准 构成 : MebSocket API 是 W3C 定义 的 ， 而 WebSocket 


人 AS ， 协 议 (RFC 6455) 及 其 扩展 则 由 HyBi Working Group (IETF) 定义 。 
“4 
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17.1 WebSocket API 
浏 览 器 提供 的 websocket API 可 谓 简 约 。 当 然 ， 简 约 背 后 隐藏 着 连接 管理 和 消息 处 
理 等 底层 细节 。 发 起 新 连接 ， 需 要 Websocket 资源 的 URL 和 一 些 应 用 回调 : 

var ws = new WebSocket('wss://example.com/socket'); © 


ws.onerror 
ws.onclose 


function (error) { ... } 名 
function () { ... 1} 自 


ws.onopen = function (){@ 
ws.send("Connection established. Hello server!"); © 


} 


ws.onmessage = function(msg) { @ 
if(msg.data instanceof BLob) { @ 
processBlob(msg.data); 
} elsef 
processText(msg.data); 
} 
} 
@ 打开 新 的 安全 WebSocket 连接 (wss) 
@ 可 选 的 回调 ， 在 连接 出 错时 调用 
@ 可 选 的 回调 ， 在 连接 终止 时 调用 
@ 可 选 的 回调 ， 在 Websocket 连接 建立 时 调用 
@ 客户 端 先 向 服务 器 发 送 一 条 消息 
@ 回调 函数 ， 服 务 器 每 发 回 一 条 消息 就 调用 一 次 
@ 根据 接收 到 的 消息 ， 决 定 调用 二 进 制 还 是 文本 处 理 逻 辑 

















这 个 API 非常 直观 。 事 实 上 ， 应 该 说 它 与 上 一 章 介 绍 的 EventSource API 很 像 。 这 
是 故意 这 么 设计 的 ， 因 为 websocket 也 提供 类 似 和 扩展 的 功能 。 当 然 ， 除 了 相似 性 
之 外 ， 还 有 很 多 重要 的 差别 。 下 面 我 们 就 逐个 介绍 。 








模拟 WebSocket 

WebSocket 已 经 经 历 了 很 多 次 版 本 升级 、 实 现 回 滚 和 安全 考验 。 好 消息 是 ，REFC 
6455 定义 的 最 新 版 本 (v13) 已 经 得 到 所 有 现代 浏览 器 支持 。 唯 一 尚未 支持 它 的 
是 Opera mini， 可 参见 caniuse.com/websockets 。 

与 使 用 腻子 脚本 模拟 SSE 类 似 (参见 16.1 节 的 “使 用 自 编 JavaScript 模拟 
EventSource”)，WebSocket 也 可 以 使 用 JavaScript 库 来 模拟 。 不 过 ， 模 拟 WebSocket 
最 难 的 地 方 不 是 API， 而 是 传输 层 ! 因此 ， 选 择 的 腻子 脚本 及 其 后 备 机 制 (XHR、 
轮 询 、EventSource、iframe 轮 询 ， 等 等 ) 对 模拟 方案 的 性 能 会 有 很 大 影响 。 
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为 简化 跨 浏 览 器 部 署 ，SockJS 等 流行 的 库 都 提供 了 类 似 WebSocket 对 象 的 实现 ， 
并 更 进一步 实现 了 支持 WebSocket 的 自 定 义 服 务 器 ， 以 及 各 种 备用 传输 方案 。 自 
定义 服务 器 和 客户 端 构 成 了 所 谓 的 “无 颖 备用 ”: 性 能 虽然 差强人意 ， 但 应 用 的 
API 不 变 。 


其 他 库 ， 比 如 Socket.I0 走 得 其 至 更 远 ， 除 提供 多 套 后 备 传 输 机 制 ， 还 实现 了 心 
跳 检 测 、 超 时 、 自 动 重 连 等 功能 

在 选择 Socket.I0 这 样 的 腻子 脚本 或 “实时 框架 ”时 ， 一 定 要 留心 其 底层 实现 ， 
以 及 客户 身 和 服务 器 的 配置 : 保证 尽 可 能 利用 原生 WebSocket 接口 以 来 最 佳 性 能 
然后 确保 备用 传输 机 制 能 满足 你 的 性 能 要 求 。 











17.1.1 WS 与 WSS 

Websocket 资源 URL 采用 了 自 定义 模式 : ws 表示 纯 文 本 通信 (如 ws://example. 
com/socket) ，wss 表示 使 用 加 密 信道 通信 (TCP+TLS)。 为 什么 不 使 用 http 而 要 自 
定义 呢 ? 





Nebsocket 的 主要 目的 ， 是 在 浏览 器 中 的 应 用 与 服务 器 之 间 提 供 优化 的 、 双 向 通信 机 
制 。 可 是 ，WebSocket 的 连接 协议 也 可 以 用 于 浏览 器 之 外 的 场景 ， 可 以 通过 非 HTTP 
协商 机 制 交 换 数据 。 考 虑 到 这 一 点 ，HyBi Working Group 就 选择 采用 了 自 定 义 的 
URL 模式 。 

一 使 用 自 定义 的 URL 模式 虽然 让 非 HTTP 协商 成 为 可 能 ， 但 实践 中 还 没有 既 

4 4 、 定 标准 可 以 作为 建立 Websocket 会 话 的 替代 担 手 机 制 。 


Nf 
人， 


17.1.2 ”接收 文本 和 二 进 制 数据 

Websocket 通信 只 涉及 消息 ， 应 用 代码 无 需 担 心 缓冲 、 解 析 、 重 建 接收 到 的 数据 。 比 
如 ， 服 务 器 发 来 了 一 不 工 让 的 淋 和 应 用 的 onmessage 回调 只 会 在 客户 端 接收 到 全 
部 数据 时 才 会 被 调用 。 


此 外 ，Wwebsocket 协议 不 作 格式 假设 ， 对 应 用 的 净 荷 也 没有 限制 : 文本 或 者 二 进 制 数 
据 都 没 问 题 。 从 内 部 看 ， 协 议 只 关注 消息 的 两 个 信息 : 净 和 荷 长 度 和 类 型 (前 者 是 一 
个 可 变 长 度 字 段 )， 据 以 区 别 UTF-8 数据 和 二 进 制 数据 。 


浏览 器 接收 到 新 消息 后 ， 如 果 是 文本 数据 ,会 自动 将 其 转换 成 DoMstring 对 象 ， 如 
果 是 二 进 制 数据 或 Blob 对 和 象 ， 会 直接 将 其 转交 给 应 用 。 唯 一 可 以 (作为 性 能 上 暗示 和 
优化 措施 ) 多 余 设 置 的 ， 就 是 告诉 浏览 器 把 接收 到 的 二 进 制 数 据 转换 成 ArrayBuffer 
而 非 Blob: 
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Var ws = new WebSocket('wss://example.com/socket'); 
ws.binaryType = "arraybuffer"; @ 


ws.onmessage = function(msg) { 
if(msg.data instanceof ArrayBuffer) { 
processArrayBuffer(msg.data); 
} elsef 
processText(msg.data); 


} 
@ 如 果 接 收 到 二 进 制 数据 ， 将 其 强制 转换 成 ArrayBuffer 





用 户 代理 可 以 将 这 个 选项 看 作 一 个 上 暗示， 以 决定 如 何 处 理 接收 到 的 二 进 制 数 

据 : 如 果 这 里 设置 为 “blob”， 那 就 可 以 放心 地 将 其 转 存 到 磁盘 上 ; 而 如 果 

设置 为 “arraybuffer”， 那 很 可 能 在 内 存 里 处 理 它 更 有 效 。 自 然 地 ， 我 们 鼓励 
用 户 代 理 使 用 更 细微 的 线索 ， 以 决定 是 否 将 到 来 的 数据 放 到 内 存 里 …… 

一 一 The WebSocket API 

W3C Candidate Recommendation 


Blob 对 象 一 般 代 表 一 个 不 可 变 的 文件 对 象 或 原始 数据 。 如 果 你 不 需要 修改 它 或 者 不 
需要 把 它 切 分 成 更 小 的 块 ， 那 这 种 格式 是 理想 的 〈 比 如 ， 可 以 把 一 个 完整 的 Blob 对 
象 传 给 img 标签 ， 参 见 15.3 节 “ 通 过 XHR 下 载 数 据 ”) 。 而 如 果 你 还 需要 再 处 理 接 
收 到 的 二 进 制 数据 ， 那 么 选择 ArrayBuffer 应 该 更 合适 。 

















使 用 JavaScript 解码 二 进 制 数据 


ArrayBuffer 表示 一 个 普通 的 、 固 定 长 度 的 二 进 制 数据 缓冲 。 不 过 ， 可 以 用 
ArrayBuffer 创建 一 或 多 个 ArrayBufferView 对 象 ， 每 一 个 都 可 以 通过 特定 的 格式 
来 展示 缓冲 中 的 内 容 。 比 如 ， 假设 我 们 需要 处 理 下 面 类 似 C 的 二 进 制 数据 结构 : 
struct someStruct { 
char username[16]; 
unsigned short id; 


float scores[32]; 
}; 


在 取得 这 个 类 型 的 ArrayBuffer 对 象 后 ， 可 以 对 同一 个 缓冲 创建 多 个 不 同 的 视图 ， 
每 个 视图 的 偏 移 量 和 数据 类 型 都 可 以 不 一 样 : 

var buffer = msg.data; 

var UsernameView = new Uint8Array(buffer, 0, 16); 

var idView = new Uint1i6Array(buffer, 16, 1); 


var scoresView = new Float32Array(buffer, 18, 32); 


console.log("ID: " + idView[0] + " username: " + UsernameView[0] ); 
for (var j = 0; j < 32; j++) { console.log(scoresView[j]) } 
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每 个 视图 都 以 父 缓冲 、 开 始 字 节 偏 移 量 和 要 处 理 的 元 素数 作为 参数 ， 其 中 偏 移 量 
根据 之 前 字段 的 大 小 计算 。 结 果 ，ArrayBuffer 和 WebSocket 实际 上 为 我 们 在 浏览 
器 中 处 理 二 进 制 数据 提供 了 所 有 必要 的 工具 。 





17.1.3 发 送 文本 和 二 进 制 数据 

建立 了 websocket 连接 后 ， 客 户 端 就 可 以 随时 发 送 或 接收 UTF-8 或 二 进 制 消息 。 
Websocket 提供 的 是 一 条 双向 通信 的 信道 ， 也 就 是 说 ， 在 同一 个 TCP 连接 上 ， 可 以 
双向 传输 数据 ; 




















var ws = new WebSocket('wss://example.com/socket'); 
ws.onopen = function () { 
socket.send("Hello server!'"); © 


socket. send(JSON. stringify({'msg': 'payload'})); © 


var buffer = new ArrayBuffer(128); 
socket.send(buffer); © 


var intview = new Uint32Array(buffer); 
socket. send(intview); @ 


var blob = new Blob([buffer]); 
socket.send(blob); @ 


} 
@ 发 送 UTF-8 编码 的 文本 消息 
@ 发 送 UTF-8 编码 的 JSON 净 荷 
@ 发 送 二 进 制 ArrayBuffer 
@@ 发 送 二 进 制 ArrayBufferView 
@ 发 送 二 进 制 Blob 





WebSocket API 可 以 接收 UTF-8 编码 的 D0Mstring 对 象 ， 也 可 以 接收 ArrayBuffer、 
ArrayBufferView 或 Blob 等 二 进 制 数据 。 但 要 注意 ， 所 有 二 进 制 数据 类 型 只 是 为 了 简 
化 API: 在 传输 中 ， 只 通过 一 位 (bit) 即 可 将 Websocket 帧 标记 为 二 进 制 或 者 文本 。 
假如 应 用 或 服务 器 需要 传输 其 他 的 内 容 类 型 ， 就 必须 通过 其 他 机 制 来 沟通 这 个 信息 。 
这 里 的 send() 方法 是 异步 的 : 提供 的 数据 会 在 客户 端 排队 ， 而 函数 则 立即 返回 。 特 
别 是 在 传输 大 文件 的 时 候 ， 千 万 别 因为 返回 快 ， 就 错误 地 以 为 数据 已 经 发 送出 去 
了 ! 要 监控 在 浏览 器 中 排队 的 数据 量 ， 可 以 查询 套 接 字 的 bufferedAmount 属性 : 
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var ws = new WebSocket('wss://example.com/socket'); 


ws.onopen = function () { 
subscribeToApplicationUpdates(function(evt) { @ 
if (ws.bufferedAmount == 0) 
ws.send(evt.data); © 
的 3 
}; 
@ 预订 应 用 更 新 (如 游戏 状态 更 新 ) 
名 检查 客户 端 缓冲 的 数据 量 
@ 如 果 缓 冲 是 空 的 ， 发 送 下 一 次 更 新 


前 面 的 例子 是 要 向 服务 器 发 送 应 用 数据 ， 但 前 提 是 客户 端 缓冲 区 已 经 没有 之 前 待 发 
送 的 数据 了 。 为 什么 非 要 做 这 个 检查 ? 所 有 WebSocket 消息 都 会 按照 它们 在 客户 端 
排队 的 次 序 逐 个 发 送 。 因 此 ， 大 量 排队 的 消息 ， 甚 至 一 个 大 消息 ， 都 可 能 导致 排 在 
它 后 面 的 消息 延迟 一 一 队 首 阻塞 ! 


为 解决 这 个 问题 ， 应 用 可 以 将 大 消息 切 分 成 小 块 ， 通 过 监控 bufferedAmount 的 值 来 
避免 队 首 阻塞 。 其 至 还 可 以 实现 自己 的 优先 队列 ， 而 不 是 盲目 都 把 它们 送 到 破 接 字 
上 排队 。 





a 
, 


很 多 应 用 都 会 生成 多 种 消息 : 有 高 优先 级 的 更 新 ， 也 有 低 优先 级 的 更 新 。 
前 者 比如 流量 控制 消息 ， 后 者 比如 后 台 传 输 。 要 实现 最 优化 传输 ， 应 用 必 
~ 须 关 心 任意 时 刻 在 套 接 字 上 排队 的 是 什么 消息 ! 














17.1.4 子 协 议 协 商 
WebSocket 协议 对 每 条 消息 的 格式 事先 不 作 任何 假设 ; 仅 用 一 位 标记 消息 是 文本 还 是 
二 进 制 ， 以 便 客户 端 和 服务 器 有 效 地 解码 数据 ， 而 除 此 之 外 的 消息 内 容 就 是 未 知 的 。 


此 外 ， 与 HTTP 或 XHR 请 求 不 同 它们 是 通过 每 次 请 求 和 响应 的 HTTP 首部 来 
沟通 元 数据 ，WebSocket 并 没有 等 价 的 机 制 。 因 此 ， 如 果 需 要 沟通 关于 消息 的 元 数 
据 ， 客 户 端 和 服务 器 必须 达成 沟通 这 一 数据 的 子 协议 。 


。 客户 端 和 服务 器 可 以 提前 确定 一 种 国定 的 消息 格式 ， 比 如 所 有 通信 都 通过 JSON 
编码 的 消息 或 者 某 种 自 定义 的 二 进 制 格式 进行 ， 而 必要 的 元 数据 作为 这 种 数据 结 
构 的 一 个 部 分 。 

。 如 果 客 户 端 和 服务 器 要 发 送 不 同 的 数据 类 型 ， 那 它们 可 以 确定 一 个 双方 都 知道 的 

消息 首部 ， 利 用 它 来 沟通 说 明 信 息 或 有 关 净 荷 的 其 他 解码 信息 。 
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。 混合 使 用 文本 和 二 进 制 销 息 可 以 沟通 净 荷 和 元 数据 ， 比 如 用 文本 消息 实现 HTTP 
首部 的 功能 ， 后 跟 包含 应 用 净 荷 的 二 进 制 消 息 。 








以 上 只 列举 了 几 种 可 能 的 策略 。 与 WebSocket 消息 的 灵活 性 和 低 延 迟 对 应 的 ， 就 是 
应 用 逻辑 必须 复杂 一 点 。 不 过 ， 消 息 的 串 行 化 和 元 数据 管理 只 是 问题 的 一 方面 ! 
确定 了 消息 的 串 行 格式 化 ， 怎 么 保证 客户 端 和 服务 器 相互 理解 ， 怎 么 确保 它们 同 
步 呢 ? 





好 在 ，WebSocket 为 此 提供 了 一 个 简单 便捷 的 子 协议 协商 API。 客 户 端 可 以 在 初次 
连接 握手 时 ， 告 诉 服 务 器 自己 支持 哪 种 协议 : 


var ws = new WebSocket('wss://example.com/socket', 
['appProtocol', 'appProtocol-v2']); O@ 


ws.onopen = function () { 
if (ws.protocol == 'appProtocol-v2') {© 
} else { 
Pe 
让 
@ 在 Websocket 握手 期 间 发 送 子 协 议 数组 
@ 检查 服务 器 选择 了 哪个 子 协议 


如 这 个 例子 所 示 ，WebSocket 构造 函数 可 以 接受 一 个 可 选 的 子 协 议 名 字 的 数组 ， 通 过 
这 个 数组 ， 客 户 端 可 以 向 服务 器 通告 自己 能 够 理解 或 希望 服务 器 接受 的 协议 。 这 个 
协议 数组 会 发 送 给 服务 器 ， 服 务 器 可 以 从 中 挑选 一 个 。 


如 果子 协议 协商 成 功 ， 就 会 触发 客户 端的 onopen 回调 ， 应 用 可 以 查询 WebSocket 对 
象 上 的 protocol 属性 ， 从 而 得 知 服务 器 选 定 的 协议 。 另 一 方面 ， 服 务 器 如 果 不 支 持 
客户 端 声明 的 任何 一 个 协议 ， 则 websocket 握手 是 不 完整 的 ， 此 时 会 触发 onerror 回 
调 ， 连 接 断 开 。 





子 协议 名 由 应 用 自己 定义 ， 且 在 初次 HTTP 担 手 期 间 发 送 给 服务 器 。 除 此 
人 4 ， 之 外 ， 指 定 的 子 协议 对 核心 Websocket API 不 会 有 任何 影响 。 


[INA 


17.2 WebSocket 协 议 


HyBi Working Group 制定 的 WebSocket 通信 协议 (RFC 6455) 包含 两 个 高 层 组 件 : 
开放 性 HTTP 握手 用 于 协商 连接 参数 ， 二 进 制 消 息 分 帧 机 制 用 于 支持 低 开销 的 基于 
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消息 的 文本 和 二 进 制 数据 传输 。 


WebSocket 协议 尝试 在 既 有 HTTP 基础 设施 中 实现 双向 HTTP 通信 ， 因 此 

也 使 用 HTTP 的 80 和 443 痛 口 …… 不 过 ， 这 个 设计 不 限于 通过 HTTP 实现 

WebSocket 通信 ， 未 来 的 实现 可 以 在 某 个 专用 端口 上 使 用 更 简单 的 握手 ， 而 
不 必 重 新 定义 么 一 个 协议 。 

一 WebSocket Protocol 

RFC 6455 


WebSocket 协议 是 一 个 独立 完善 的 协议 ， 可 以 在 浏览 器 之 外 实现 。 不 过 ， 它 的 主要 
应 用 目标 还 是 实现 浏览 器 应 用 的 双向 通信 。 














17.2.1 二 进 制 分 帧 层 

客户 端 和 服务 器 WebSocket 应 用 通过 林 于 消息 的 API 通信 : 发 送 端 提供 任意 UTF-8 
或 二 进 制 的 净 荷 ， 接 收 端 在 整个 消息 可 用 时 收 到 通知 。 为 此 ，WebSocket 使 用 了 自 
定义 的 二 进 制 分 帧 格式 (图 17-1)， 把 每 个 应 用 消息 切 分 成 一 或 多 个 帧 ， 发 送 到 目 
的 地 之 后 再 组 装 起 来 ， 等 到 接收 到 完整 的 消息 后 再 通知 接收 端 。 





























17-1: WebSocket 帧 格式 ，2~14 字 节 + 净 荷 

。 帧 
最 小 的 通信 单位 ， 包 含 可 变 长 度 的 帧 首部 和 净 荷 部 分 ， 净 和 荷 可 能 包含 完整 或 部 分 
应 用 消息 。 

。 消息 
一 系列 帧 ， 与 应 用 消息 对 等 。 

是 否 把 消息 分 帧 由 客户 端 和 服务 器 实现 决定 。 事 实 上， 应 用 可 以 对 个 别 WebSocket 

帧 或 如 何 分 帧 之 无 概念 。 即 便 如 此 ， 理 解 每 个 WebSocket 帧 也 很 重要 。 

。 每 一 帧 的 第 一 位 (FIN) 表示 当前 帧 是 不 是 消息 的 最 后 一 帧 。 一 条 消息 有 可 能 只 
对 应 一 帧 。 
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。 操作 码 (4 位 ) 表示 被 传输 帧 的 类 型 : 传输 应 用 数据 时 ， 是 文本 〈1) 还 是 二 进 制 
(2) ; 连接 有 效 性 检查 时 ， 是 关闭 (8)、 呼 叫 (ping，9) 还 是 回应 (pong，10) 。 
。 掩 码 位 表示 净 荷 是 否 有 掩 码 (只 适用 于 客户 端 发 送 给 服务 器 的 消息 )。 
。 净 荷 长 度 由 可 变 长 度 字 段 表 示 : 
。 如 果 是 0~125， 就 是 净 答 长 度 ，; 
4 如 果 是 126， 则 接 下 来 2 字 节 表示 的 16 位 无 符号 整数 才 是 这 一 帧 的 长 度 ，; 
。 如 果 是 127， 则 接 下 来 8 字 节 表示 的 64 位 无 符号 整数 才 是 这 一 帧 的 长 度 。 
。 掩 码 键 包含 32 位 值 ， 用 于 给 净 荷 加 掩护 。 
。 净 荷 包含 应 用 数据 ， 如 果 客 户 端 和 服务 器 在 建立 连接 时 协商 过 ， 也 可 以 包含 自 定 














义 的 扩展 数据 。 

过 

se | 所 有 客户 端 发 送 帧 的 净 荷 都 要 使 用 帧 首部 中 指定 的 值 加 捧 码 ， 这 样 可 以 防 
全 4， 止 客户 端 中 运行 的 恶意 脚本 对 不 支持 WebSocket 的 中 间 设备 进行 缓存 投 








心 ， 毒 攻击 (cache poisoning attack)。 要 了 解 这 种 攻击 的 细节 ， 请 参考 W2SP 
2011 的 论文 “Talking to Yourself for Fun and Profit” (http://w2spconf.com/ 
2011/papers/websocket.pdf ) 。 


算 下 来 ， 服务器 发 送 的 每 个 WebSocket 帧 会 产生 2~10 字 节 的 分 帧 开销 。 而 客户 端 
必须 发 送 掩 码 键 ， 这 又 会 增加 4 字 节 ， 结 果 就 是 6~14 字 市 的 开销 。 除 此 之 外 ， 没 
有 其 他 元 数据 (比如 首部 字段 或 其 他 关于 净 茶 的 信息 ) : 所 有 WebSocket 通信 都 是 
通过 交换 帧 实现 的 ， 而 帧 将 净 荷 视 为 不 透明 的 应 用 数据 块 。 











WebSocket 的 多 路 复 用 及 队 首 阻塞 


WebSocket 很 容易 发 生 队 首 阻塞 的 情况 : 消息 可 能 会 被 分 成 一 或 多 个 帧 ， 但 不 同 
消息 的 帧 不 能 交错 发 送 ， 因 为 没有 与 HTTP 2.0 分 帧 机 制 中 “ 流 ID” 对 等 的 字段 
(参见 12.3.2 节 “ 流 、 消 息 和 帧 ”) 。 


显然 ， 如 果 一 个 大 消息 被 分 成 多 个 WebSocket 帧 ， 就 会 阻塞 其 他 消息 的 帧 。 如 果 
你 的 应 用 不 容许 有 交付 延迟 ， 那 可 以 小 心 控制 每 条 消息 的 净 荷 大 小 ， 甚 至 可 以 考 
虑 把 大 消息 拆 分 成 多 个 小 消息 ! 

WebSocket 不 支持 多 路 复 用 ， 还 意味 着 每 个 WebSocket 连接 部 需要 一 个 专门 的 
TCP 连接 。 对 于 HTTP 1.x 而 言 ， 由 于 浏览 器 针对 每 个 来 源 有 连接 数量 限制 ， 因 此 
可 能 会 导致 问题 (参见 11.3 节 中 的 “消耗 客户 端 和 服务 器 资源 ) 。 

好 在 ，HyBi Working Group 正 着 手 制定 的 新 的 “Multiplexing Extension for 
WebSockets” (WebSockets 多 路 复 用 扩展 ) 会 解决 这 个 问题 : 
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这 个 扩展 通过 封装 帧 并 加 上 信道 ID， 可 以 让 一 个 TCP 连接 支持 多 个 虚 
拟 WebSocket 连接 ……… 这 个 多 路 复 用 扩展 维护 独立 的 逻辑 信道 ， 每 个 还 
辑 信道 与 独立 的 WebSocket 连接 没有 差别 ， 和 包括 独立 的 握手 首部 。 


WebSocket Multiplexing (Draft 10) 


有 了 这 个 扩展 后 ， 多 个 WebSocket 连接 (信道 ) 就 可 能 在 同一 个 TCP 连接 上 得 到 
复 有 用。 可是， 每 个 信道 依旧 容易 产生 队 首 阻塞 问题 | 可 能 的 解决 方案 是 使 用 不 同 
的 信道 ， 或 者 专用 TCP 连接 ， 多 路 并 行 发 送 消息 。 

最 后 ， 注 意 前 面 的 扩展 仅 对 HTTP 1.x 连 接 是 必要 的 。 虽 然 通过 HTTP 2.0 传输 
WebSocket 帧 的 官方 规范 尚未 发 布 ， 但 相对 来 说 就 容易 多 了 。 因 为 HTTP 2.0 内 
置 了 流 的 多 路 复 用 ， 只 要 通过 HTTP 2.0 的 分 帧 机 制 来 封装 WebSocket 帧 ， 多 个 
WebSocket 连接 就 可 以 在 一 个 会 话 中 传输 。 














17.2.2 协议 扩展 


WebSocket 规范 允许 对 协议 进行 扩展 : 数据 格式 和 WebSocket 协议 的 语义 可 以 通过 
新 的 操作 码 和 数据 字段 扩展 。 en 
因为 它 人 允许 客户 端 和 服务 器 在 基本 的 WebSocket 分 帧 层 之 上 实现 更 多 功能 ， 又 不 需 
要 应 用 代码 介入 或 协作 。 


WebSocket 协议 扩展 有 哪些 例子 ”人 负责 制定 WebSocket 规范 的 HyBi Working Group 
就 进行 了 两 项 扩展 。 

















。 多 路 复 用 扩展 (A Multiplexing Extension for bp 
这 个 扩展 可 以 将 WebSocket 的 逻辑 连接 独立 出 来 ， 实 现 共享 底层 的 TCP 连接 。 





。 压缩 扩展 (Compression Extensions for WebSocket) 
给 WebSocket 协议 增加 了 压缩 功能 


如 前 所 述 ， 每 个 WebSocket 连接 都 需要 一 个 专门 的 TCP 连接 ， 这 样 效率 很 低 。 多 
路 复 用 扩展 解决 了 这 个 问题 。 它 使 用 “信道 ID” 扩 展 每 个 WebSocket 帧 ， 从 而 实现 
多 个 虚拟 的 WebSocket 信道 共享 一 个 TCP 连接 。 


类 似 地 ， 基 本 的 WebSocket 规范 没有 压缩 数据 的 机 制 或 建议 ， 每 个 帧 中 的 净 葆 就 是 
应 用 提供 的 净 荷 。 虽 然 这 对 优化 的 二 进 制 数据 结构 不 是 问题 ， 但 除非 应 用 实现 自己 
的 压缩 和 解压 缩 逮 辑 ， 否 则 很 多 情况 下 都 会 造成 传输 载荷 过 大 的 问题 。 实 际 上 ， 压 
缩 扩展 就 相当 于 HTTP 的 传输 编码 协商 。 


要 使 用 扩展 ， 客 户 端 必 须 在 第 一 次 的 Upgrade 握手 中 通知 服务 器 ， 服 务 器 必须 选择 
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并 确认 要 在 商定 连接 中 使 用 的 扩展 。 下 面 我 们 就 来 看 一 个 Upgrade 的 例子 。 





WebSocket 多 路 复 用 与 压缩 在 现实 中 的 应 用 


堆 止 到 2013 年 年 中 ，WebSocket 的 多 路 复 用 还 没有 得 到 任何 主流 浏览 器 支持 。 类 
似 地 ， 对 压缩 扩展 的 支持 也 很 有 限 : 谷歌 Chrome 和 最 新 的 WebKit 浏览 器 可 能 会 
向 服务 器 发 送 “x-webkit-deflate-frame” 扩 展 。 然 而 这 个 deflate-frame 是 基于 该 标 
准 的 过 时 版 本 实现 的 ， 将 来 可 能 会 被 抛弃 。 

压缩 扩展 的 早期 版 本 是 “ 逐 帧 ”压缩 ， 这 对 要 分 成 多 个 帧 的 大 消息 显然 不 是 最 佳 
方法 。 最 新 版 本 已 经 修改 为 以 消息 为 单位 压缩 ， 这 是 好 消息 。 坏 消息 是 ， 以 消息 
为 单位 压缩 还 是 实验 性 的 ， 目 前 尚未 得 到 主流 浏览 器 支持 。 

结果 ， 就 是 应 用 需要 密切 关注 传输 的 数据 类 型 ， 并 在 可 行 的 情况 下 采用 自己 的 压 
缩 方 案 。 换 向 话说 ， 至 少 在 所 有 主流 浏览 器 原生 支持 WebSocket 之 前 ， 你 要 考虑 
这 个 方案 。 这 对 移动 应 用 万 为 重要 ， 因 为 移动 应 用 中 的 每 个 字 节 都 可 能 给 用 户 带 
来 不 必要 的 成 本 。 











17.2.3 “HTTP 升级 协商 
WebSocket 协议 提供 了 很 多 强大 的 特性 : 基于 消息 的 通信 、 自 定义 的 二 进 制 分 帧 层 、 
子 协议 协商 、 可 选 的 协议 扩展 ， 等 等 。 换 句 话 说 ， 在 交换 数据 之 前 ， 客 户 端 必须 与 
服务 器 协商 适当 的 参数 以 建立 连接 。 


利用 HTTP 完成 握手 有 几 个 好 处 。 首 先 ， 让 WebSockets 与 现 有 HTTP 基础 设施 兼 
容 : WebSocket 服务 器 可 以 运行 在 80 和 443 端口 上 ， 这 通常 是 对 客户 端 唯一 开放 
的 端口 。 其 次 ， 让 我 们 可 以 重用 并 扩展 HTTP 的 Upgrade 流 ， 为 其 添加 自 定义 的 
WebSocket 首部 ， 以 完成 协商 。 





























。 Sec-WebSocket-Version 
客户 端 发 送 ， 表 示 它 想 使 用 的 WebSocket 协议 版 本 (“13” 表 示 RFC 6455) 。 如 
果 服 务 器 不 支持 这 个 版 本 ， 必 须 回 应 自己 支持 的 版 本 。 





。 Sec-WebSocket-Key 
客户 端 发 送 ， 自 动 生 成 的 一 个 键 ， 作 为 一 个 对 服务 器 的 “挑战 "， 以 验证 服务 器 
支持 请 求 的 协议 版 本 。 


。 Sec-WebSocket-Accept 
服务 器 响应 ， 包 含 Sec-WebSocket-Key 的 签名 值 ， 证 明 它 支持 请 求 的 协议 版 本 。 
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。 Sec-WebSocket-Protocol 
用 于 协商 应 用 子 协议 : 客户 端 发 送 支 持 的 协议 列表 ， 服 务 器 必须 只 回应 一 个 协 
议 名 。 

。 Sec-WebSocket-Extensions 
用 于 协商 本 次 连接 要 使 用 的 WebSocket 扩展 : 客户 端 发 送 支 持 的 扩展 ， 服 务 器 通 
过 返回 相同 的 首部 确认 自己 支持 一 或 多 个 扩展 。 














有 了 这 些 协商 字段 ， 就 可 以 在 客户 端 和 服务 器 之 间 进 行 HITP Upgrade 并 协商 新 的 
WebSocket 连接 了 了 : 


GET /socket HTTP/1.1 

Host: thirdparty.com 

Origin: http://example.com 

Connection: Upgrade 

Upgrade: websocket @ 

Sec-Websocket-Version: 13 @ 

Sec-WebSocket-Key: dGhLIHNhbxBsZSBub25jZQ== © 

Sec-WebSocket-ProtocoL: appProtocol, appProtocol-v2 @ 
Sec-WebSocket-Extensions: x-webkit-deflate-message, x-custom-extension © 


@ 请 求 升级 到 WebSocket 协议 

@ 客户 端 使 用 的 WebSocket 协议 版 本 

@ 自动 生成 的 键 ， 以 验证 服务 器 对 协议 的 支持 
@@ 可 选 的 应 用 指定 的 子 协议 列表 

@ 可 选 的 客户 端 支 持 的 协议 扩展 列表 


与 浏览 器 中 客户 端 发 起 的 任何 连接 一 样 ，WebSocket 请 求 也 必须 遵守 同 源 策略 : 浏 
览 器 会 自动 在 升级 握手 请 求 中 追加 Origin 首部 ， 远 程 服务 器 可 能 使 用 CORS 判断 接 
受 或 拒绝 蜂 源 请 求 [参见 15.2 节 “ 跨 源 资源 共享 (CORS)”]。 要 完成 握手 ， 服 务 
器 必须 返回 一 个 成 功 的 “Switching Protocols”( 切 换 协 议 ) 响应 ， 并 确认 选择 了 窜 
户 端 发 送 的 哪个 选项 : 





HTTP/1.1 101 Switching Protocols © 

Upgrade: websocket 

Connection: Upgrade 

Access-Control-Allow-Origin: http://example.con @ 
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+x00= © 
Sec-WebSocket-ProtocoL: appProtocol-v2 @ 
Sec-WebSocket-Extensions: x-custom-extension © 


@ 101 响应 码 确 认 升 级 到 WebSocket 协议 
@ CORS 首部 表示 选择 同意 跨 源 连 接 
@ 签名 的 键 值 验证 协议 支持 
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择 的 应 用 子 协议 


@ 服务 器 
务 器 选择 的 WebSocket 扩展 


选 
@ 服务 器 选 
战 的 答案 : 将 Sec-Websocket-Key 的 内 容 与 标准 定义 的 唯一 GUID 字符 串 


拼接 起 来 ， 计 算出 SHA1 散 列 值 ， 结 果 是 一 个 base-64 编码 的 字符 串 ， 把 
这 个 字符 串 发 给 客户 端 即 可 。 








Ey 所 有 兼容 REC 6455 的 WebSocket 服务 器 都 使 用 相同 的 算法 计算 客户 端 挑 
EA 
(0% 











最 低 限 度 ， 成 功 的 WebSocket 握手 必须 是 客户 端 发 送 协议 版 本 和 自动 生成 的 挑战 
值 ， 服 务 器 返回 101 HTTP 响应 码 (Switching Protocols) 和 散 列 形式 的 挑战 答案 ， 
确认 选择 的 协议 版 本 : 


。 客户 端 必须 发 送 Sec-WebSocket-Version 和 Sec-WebSocket-Key; 

。 服务 器 必须 返回 Sec-WebSocket-Accept 确认 协议 ; 

。 客户 端 可 以 通过 Sec-WebSocket-Protocol 发 送 应 用 子 协 议 列表 ， 

。 服务 器 必须 选择 一 个 子 协 议 并 通过 Sec-Websocket-ProtocoL 返回 协议 名 ; 如 果 服 
务 串 不 文 持 任 何 一 个 协议 ， 连接 断 开 ， 

。 客户 端 可 以 通过 sec-WebSocket-Extensions 发 送 协 议 扩 展 ， 

。 服务 器 可 以 通过 Sec-WebSocket-Extensions 确认 一 或 多 个 扩展 ， 如 果 服 务 器 没有 
返回 扩展 ， 则 连接 不 支持 扩展 。 


最 后 ， 前 述 握手 完成 后 ， 如 果 握 和 手 成 功 ， 该 连接 就 可 以 用 作 双 向 通 2 
WebSocket 消息 。 从 此 以 后 ， 客 户 端 与 服务 器 之 间 不 会 再 发 生 HTTP 通信 ， 一 切 由 
WebSocket 协议 接管 。 























代理 、 中 间 设 备 与 WebSocket 


实践 中 ， 考 虑 到 安全 和 保密 ， 很 多 a RR a 口 ， 通常 只 有 80 
(HTTP) 和 443 (HTTPS)。 正 因为 如 此 ，WebSocket 协商 是 通过 HTTP Upgrade 
流 进行 的 ， 这 样 可 以 确保 与 现 有 网 络 策略 及 基础 设施 兼容 。 


不 过 ,正如 4.1 节 的 “Web 代理 、 中 间 设 备 、TLS 与 新 协议 ”所 说 ， 很 多 现 有 的 
HTTP 中 间 设 备 可 能 不 理解 新 的 WebSocket 协议 ， 而 这 可 能 导致 各 种 问题 : 盲目 
的 连接 升级 、 意 外 缓冲 WebSocket 帧 、 不 明 就 里 地 修改 内 容 、 把 WebSocket 流量 
误 当 作 不 完整 的 HTTP 通信， 等 等 。 


WebSocket 的 Key 和 Accept 握手 可 以 解决 其 中 一 些 问题 这 是 服务 器 的 一 个 安全 
策略 ， 而 盲目 “升级 ”连接 的 中 间 设 备 可 能 并 不 理解 WebSocket 协议 。 虽 然 这 个 
预防 措施 对 某 些 代理 可 以 解决 问题 ， 但 对 于 那些 “延明 代理 ”还 是 不 行 ， 它 们 可 
能 会 分 析 并 意外 地 修改 数据 。 
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解决 之 道 ? 建立 一 条 端 到 端的 安全 通道 。 比 如 ,使 用 WSS 1 在 执行 HTTP 
Upgrade 握手 之 前 ， 先 协商 一 次 TLS 会 话 ， 在 客户 端 与 服务 器 之 间 建 立 一 条 加 密 
通道 ， 就 可 以 解决 前 述 所 有 问题 。 这 个 方案 尤其 适合 移动 客户 广 ， 因 为 它们 的 流 
量 经 常 要 穿越 各 种 代理 服务 ， 这 些 代理 服务 很 可 能 不 认识 WebSocket。 





17.3 WebSocket 使 用 场景 及 性 能 


Websocket API 提供 一 个 简单 的 接口 ， 能 够 在 客户 端 与 服务 器 之 间 实 现 基于 消息 
的 双向 通信 ， 可 以 是 文本 数据 ， 可 以 是 二 进 制 数据 : 把 WebSocket URL 传递 给 构 
造 国 数 ， 设 置 几 个 JavaScript 回调 函数 ， 就 好 了 剩 下 的 就 全 都 由 浏览 器 负责 
了 。 再 加 上 WebSocket 协议 提供 的 二 进 制 分 帧 、 可 扩展 性 以 及 子 协议 协商 ， 使 得 
WebSocket 成 为 在 浏览 器 中 采用 自 定义 应 用 协议 的 最 佳 选择 。 


不 过 ， 就 跟 以 前 关于 性 能 的 讨论 一 样 ， 虽 然 WebSocket 协议 的 实现 复杂 性 对 应 
用 隐藏 了 ， 但 何 时 以 及 如 何 使 用 WebSocket， 考 良 置 疑 会 对 性 能 产生 巨大 影响 。 
WebSocket 不 能 取代 XHR 或 SSE， 而 要 获得 最 佳 性 能 ， 我 们 必须 善于 利用 它 的 
长 处 ! 





























请 参考 15.8 节 “XHR 使 用 场景 及 性 能 ”和 16.3 节 “SSE 使 用 场景 及 性 
全 4 能"， 以 了 解 各 种 传输 机 制 的 性 能 特点 。 








17.3.1 请 求 和 响应 流 
WebSocket 是 唯一 一 个 能 通过 同一 个 TCP 连接 实现 双向 通信 的 机 制 (图 17-2)， 客 
户 端 和 服务 器 随时 可 以 交换 数据 。 因 此 ，WebSocket 在 两 个 方向 上 都 能 保证 文本 和 
二 进 制 应 用 数据 的 低 延迟 交付 。 


。 XHR 是 专门 为 “事务 型 ”请 求 / 响 应 通信 而 优化 的 : 客户 端 向 服务 器 发 送 完 整 
的 、 格 式 良 好 的 HTTP 请 求 ， 服 务 器 返回 完整 的 响应 。 这 里 不 支持 请 求 流 ， 在 
Streams API 可 用 之 前 ， 没 有 可 靠 的 跨 浏览 器 响应 流 API。 

。 SSE 可 以 实现 服务 器 到 客户 端的 高 效 、 低 延迟 的 文本 数据 流 : 客户 端 发 起 SSE 连 
接 ， 服务器 使 用 事件 源 协 议 将 更 新 流 式 发 送 给 客户 端 。 客 户 端 在 初次 握手 后 ， 不 
能 向 服务 器 发 送 任何 数据 。 
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XHR 轮 询 WebSocket 





一 > HTTP 协 议 一 J EventSource 协 议 一 J WebSocket 协 议 








17-2: XHR、SSE 和 WebSocket 的 通信 流 比 较 





传播 与 排队 延迟 


把 传输 机 制 从 XHR 切换 为 SSE 或 WebSocket 并 不 会 减少 客户 详 与 服务 器 间 的 往 
返 次 数 ! 不 管 什 么 传输 机 制 ， 数 据 包 的 传播 延迟 都 一 样 。 不 过 ， 除 了 传播 延迟 ， 
还 有 一 个 排队 允 迟 消息 在 被 发 送 给 另 一 端 之 前 必须 在 客户 端 或 服务 器 上 等 待 
的 时 间 。 

对 XHR 轮 询 而 言 ， 排 队 延 迟 就 是 客户 田 轮 询 间隔 : 服务 器 上 的 消息 可 用 之 后 ， 必 
须 等 到 下 一 次 客户 疗 XHR 请 求 才 能 发 送 (参见 15.7.1 节 的 “XHR 轮 询 的 性 能 建 
模 ”)。 相 对 来 说 ，SSE 和 WebSocket 使 用 持久 连接 ， 这 样 服务 器 (和 客户 端 
如 果 是 WebSocket) 就 可 以 在 消息 可 用 时 立即 发 送 它 。 

综 上 所 述 ，SSE 和 WebSocket 的 “ 低 延 迟 交 付 ” 专 指 消除 了 消息 的 排队 延迟 。 我 
们 还 没 发 现 怎 么 让 WebSocket 数据 包 跑 得 比 光 还 快 ! 














17.3.2 ”消息 开销 

建立 了 WebSocket 连接 后 ， 客 户 端 和 服务 器 通过 WebSocket 协议 交换 数据 : 应 用 消 
息 会 被 拆 分 为 一 或 多 个 帧 ， 每 个 帧 会 添加 2~14 字 节 的 开销 。 而 且 ， 由 于 分 帧 是 按 
照 自 定 义 的 二 进 制 格式 完成 的 ，UTE-8 和 二 进 制 应 用 数据 可 以 有 效 地 通过 相同 的 机 
制 编码 。 这 一 点 与 XHR 和 SSE 比如 何 呢 ? 
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。 SSE 会 给 每 个 消息 添加 5 字 节 ， 但 仅 限 于 UTF-8 内 容 ， 参 见 16.2 市 “Event Stream 
协议 ”。 

。 HTTP 1.x 请 求 (XHR 及 其 他 常规 请 求 ) 会 携带 500~800 字 节 的 HTTP 元 数据 ， 
加 上 cookie， 参 见 11.5 节 “ 度 量 和 控制 协议 开销 ”。 

ee ee he 见 12.3.8 节 “ 首 部 压缩 ”。 
事实 上 ， 如 果 请 求 都 不 修改 首部 ， 那 么 开销 可 以 低 至 8 字 节 1 





二 





记 住 ,这 里 的 开销 数 不 包 括 卫 、TCP 和 TLS 分 帧 的 开销 ， 后 者 一 共 会 给 
人 民 4 ， 每 个 消息 增加 60~100 字 节 ， 无 论 使 用 的 是 什么 应 用 协议 ， 参 见 4.7.4 节 
个 ，“TLS 记录 大 小 ”。 








17.3.3 ”数据 效率 及 压缩 
通过 常规 的 HTTP 协商 ， 每 个 XHR 请 求 都 可 以 协商 最 优 的 传输 编码 格式 (如 对 文 
本 数据 采用 gzip 压缩 )。 类 似 地 ，SSE 局 限于 UTF-8 文本 数据 ， 因 此 事件 流 数据 可 
以 在 整个 会 话 期 间 使 用 gzip 压缩 。 


而 使 用 WebSocket 时 ， 情 况 要 复杂 一 些 : WebSocket 可 以 传输 文本 和 二 进 制 数据 ， 
因此 压缩 整个 会 话 行 不 通 。 二 进 制 的 净 茶 也 可 能 已 经 压缩 过 了 ! 为 此 ，WebSocket 
必须 实现 自己 的 压缩 机 制 ， 并 针对 每 个 消息 选择 应 用 。 


站 下 人 和 征订 TEN9 仆 下风 放 全 是 区 本 全 和 直入 全 下 币 和 生生 这 个 
扩展 尚未 得 到 任何 浏览 器 支持 。 因 此 ， 除 非 应 用 通过 细致 优化 自己 的 二 进 制 净 荷 实 
现 自己 的 压缩 逻辑 (参见 17.1.2 节 的 “使 用 JavaScript 解码 二 进 制 数 据 ”)， 同 时 也 
针对 文本 消息 实现 自己 的 压缩 逻辑 ， 否 则 传输 数据 过 程 中 一 定 会 产生 很 大 的 字 节 
开销 ! 

















Chrome 和 某 些 WebKit es 览 器 支持 WebSocket 协议 压缩 扩展 的 老 版 本 
(以 帧 为 单位 压缩 ) ， 参 见 17.2.2 节 “WebSocket 多 路 复 用 与 压缩 在 现实 中 
”的 应 用 ”。 

















17.3.4 自 定 义 应 用 协议 
浏览 器 是 为 HTTP 数据 传输 而 优化 的 ， 它 理解 HTTP 协议 ， 提 供 各 种 服务 ， 比 如 认 
证 、 缓 存 、 压 缩 ， 等 等 。 于 是 ，XHR 请 求 自然 而 然 就 继承 了 所 有 这 些 功 能 


相对 来 说 ， 流 式 数 据 处 理 可 以 让 我 们 在 客户 端 和 服务 器 间 自 定义 协议 ， 代 价 是 错过 
浏览 器 提供 的 很 多 服务 : 初次 HTTP 握手 可 以 执行 某 些 连接 参数 的 协商 ， 而 一 旦 建 
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并 会 话 ， 所 有 后 续 客户 端 与 服务 器 间 的 数据 流 对 浏览 器 都 将 是 不 透明 的 。 这 样 来 看 ， 
自 定义 应 用 协议 的 灵活 性 也 有 缺点 ， 应 用 可 能 必须 实现 自己 的 逻辑 来 填充 某 些 功 能 
空白 ， 比 如 缓存 、 状 态 管理 、 元 数据 交付 ， 等 等 。 


增 人 








初始 的 HTTP Upgrade 担 手 可 以 让 服务 器 利用 既 有 的 HTTP cookie 机 制 来 
AS 。 验 证 用 户 。 如 果 验 证 失败 ， 服 务 器 可 以 拒绝 WebSocket 升级 。 




















利用 浏览 器 和 中 间 设 备 的 缓存 

使 用 常规 HTTP 有 很 多 明显 的 优势 。 问 自己 一 个 简单 的 问题 : 客户 总 会 不 会 因 缓 
存 接收 到 的 数据 而 受益 ? 或 者 中 间 设 备 如 果 缓 存 数 据 ， 是 否 可 以 优化 对 该 数据 的 
交付 ? 

举 个 例子 ，WebSocket 支持 二 进 制 传输 ， 因 此 应 用 可 以 流 式 传输 任意 图 片 而 没有 
开销 ! 然而 ， 由 于 图 片 是 采用 自 定义 协议 交付 的 ， 它 不 会 被 保存 到 浏览 器 或 任何 
中 间 设 备 (如 CDN) 的 缓存 中 。 结 果 ， 就 可 能 给 客户 闹 造 成 不 必要 的 下 载 ， 给 来 
源 服 务 器 带 来 相当 高 的 流量 。 同 样 的 道理 也 适用 于 视频 、 文 本 等 数据 格式 。 

因此 ， 要 根据 应 用 选择 合适 的 传输 机 制 | 和 就 是 使 用 


WebSocket 交付 无 需 缓存 的 数据 ， 如 实时 更 新 和 应 用 “控制 ”消息 ， 后 者 再 触发 
XHR 请 求 通过 HTTP 协议 取得 其 他 资源 。 








17.3.5 ”部署 WebSocket 基 础 设施 


HTTP 是 专 为 短 时 突 发 性 传输 设计 的 。 于 是 ， 很 多 服务 器 、 代 理 和 其 他 中 间 设 备 的 
HTTP 连接 空闲 超时 设置 都 很 激进 。 而 这 显然 是 我 们 在 持久 的 WebSocket 会 话 中 所 
不 愿意 看 到 的 。 为 解决 这 个 问题 ， 要 考虑 三 个 方面 ， 


。 位 于 各 自 网 络 中 的 路 由 器 、 负 载 均衡 器 和 代理 ， 
。 外 部 网 络 中 透明 、 确 定 的 代理 服务 器 〈 如 ISP 和 运营 商 的 代理 ) ; 
。 客户 网 络 中 的 路 由 器 、 防 火 墙 和 代理 。 


我 们 没有 权限 控制 客户 网 络 的 策略 。 事 实 上 ， 某 些 网 络 其 至 会 完全 Ww WebSocket 
通信 ， 而 这 正 是 必须 有 备用 机 制 的 原因 。 类 似 地 ， 我 们 也 没有 权限 控制 外 部 网 络 
中 的 代理 。 可 是 ， 这 里 可 以 借助 TLS ! 通过 建立 一 打 喘 到 端的 加 密 信 道 ， 可 以 让 
WebSocket 通信 绕 过 所 有 中 间 代 理 。 














使 用 TLS 不 会 阻止 中 间 设 备 超时 断 开 空闲 的 TCP 连接 。 可 是 ， 实 践 中 ， 
4 。 WebSocket 会 话 协商 的 成 功率 越 来 越 高 ， 这 样 也 有 助 于 增加 连接 超时 的 


全 间隔 。 
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最 后 ， 就 是 我 们 自己 部 署 并 管理 的 基础 设施 ， 需 要 经 常 关 注 和 调 优 。 就 跟 我 们 经 常 
抱怨 客户 和 外 部 网 络 一 样 ， 我 们 自己 家 的 问题 其 实 一 点 也 不 少 。 通 信 路 径 上 的 每 一 
台 负 载 均 衡器 、 路 由 器 和 Web 服务 器 都 必须 针对 长 时 连接 进行 调 优 。 


例如 ，Nginx 1.3.13+ 可 以 代理 WebSocket 通信 ， 但 默认 设置 了 激进 的 60 秒 超时 1! 
为 了 突破 这 个 限制 ， 我 们 必须 明确 定义 更 长 的 超时 : 





Location /websocket { 
proxy_pass http://backend; 
proxy_http_version 1.1; 
proxy_set_header Upgrade Shttp_upgrade; 
proxy_set_header Connection "upgrade"; 
proxy_read_timeout 3600; 


proxy_send_timeout 3600; © 
} 


@ 设置 两 次 读 操作 间 的 超时 为 60 分 钟 
@ 设置 两 次 写 操作 间 的 超时 为 60 分 钟 


类 似 地 ，Nginx 服务 器 前 面 经 常 少不了 要 部 署 一 台 负 载 均 衡器 ， 比 如 HAProxy。 毫 
不 奇怪 ， 在 此 也 要 采取 相同 的 策略 ， 以 HAProxy 为 例 : 





defauLts http 
timeout connect 30s 
timeout client 30s 
timeout server 30s 
timeout tunnel 1h © 


@ 为 专用 信道 设置 60 分 钟 的 不 活动 超时 


前 面 例 子 的 关键 在 于 额外 的 “信道 ”超时 。 对 HAProxy 来 说 ，connect、client 和 
server 超时 只 适用 于 初始 的 HTTP Upgrade 握手 ， 而 一 旦 升级 完成 ， 超 时 就 会 由 信 
道 (tunnel) 值 控制 。 


Nginx 和 HAProxy 只 是 我 们 数据 中 心 内 几 百 种 服务 器 、 代 理 和 负载 均衡 器 中 的 两 
种 。 我 不 可 能 在 这 里 把 所 有 可 能 的 配置 项 都 罗列 出 来 。 前 面 的 例子 只 是 为 了 说 明 大 
多 数 基础 设施 都 需要 自 定 义 的 配置 ， 才 能 顺利 处 理 长 时 会 话 。 请 记 住 ， 在 实现 应 用 
的 持久 连接 之 前 ， 首 先 要 保证 基础 设施 的 配置 正确 。 








5 


4: 长 时 连接 和 空闲 会 话 会 占用 所 有 中 间 设 备 及 服务 器 的 内 存 和 套 接 字 资源 。 
AS 
4 

















。 实 际 上 ， 短 超时 经 常 被 视 为 安全 、 资 源 管理 及 运 维 的 预防 措施 。 无 论 部 署 
WebSocket、SSE， 还 是 HTTP 2.0， 都 有 赖 于 长 时 会 话 ， 都 会 对 运 维 提出 
新 的 挑战 。 
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17.4 性 能 检查 表 


部 署 高 性 能 的 WebSocket 服务 要 求 细 致 地 调 优 和 考量 ， 无 论 在 客户 端 还 是 在 服务 器 
上 。 可 以 参考 下 列 要 点 。 


。 使 用 安全 WebSocket (基于 TLS 的 WSS) 实现 可 靠 的 部 署 。 
。 密切 关 广 肛 子 脚本 的 性 能 (如 果 使 用 腻子 脚本 )。 

。 利用 子 协 议 协商 确定 应 用 协议 。 

。 优化 二 进 制 净 荷 以 最 小 化 传输 数据 。 

。 考虑 压缩 UTF-8 内 容 以 最 小 化 传输 数据 。 

。 设置 正确 的 二 进 制 类 型 以 接收 二 进 制 净 荷 。 

。 监控 客户 端 缓冲 数据 的 量 。 

。 切 分 应 用 消息 以 避免 队 首 阻塞 。 

。 合用 的 情况 下 利用 其 他 传输 机 制 。 


最 后 但 同样 重要 的 是 ， 为 移动 应 用 而 优化 ! 实时 推送 对 于 手持 设备 而 言 ， 反 倒 可 能 
造成 负面 影响 ， 因 为 手持 设备 的 电池 始终 很 宝贵 。 这 并 不 代表 不 能 在 移动 应 用 中 使 
用 WebSocket。 相 反 ，WebSocket 其 实 是 一 个 高 效 的 传输 机 制 ， 但 一 定 要 确保 注意 
以 下 问题 : 


。 8.1 市 “市 约 用 电 ”; 

。 8.2 市 “消除 周期 性 及 无 效 的 数据 传输 ”; 
。 8.2 市 中 的 “内 格 尔 及 有 效 的 服务 器 推送 ”; 
。 以 及 8.2 市 之 后 的 “消除 不 必要 的 长 连接 ”。 
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WebRTL 





Web Real-Time Communication (Web 实时 通信 ，WebRTC) 由 一 组 标准 、 协 议和 
JavaScript API 组 成 ， 用 于 实现 浏览 器 之 间 ( 端 到 端 ) 的 音频 、 视 频 及 数据 共享 。 
WebRTC 使 得 实时 通信 变 成 一 种 标准 功能 ， 任 何 Web 应 用 都 无 需 借助 第 三 方 插件 和 
专 有 软件 ， 而 是 通过 简单 的 JavaScript API 即 可 利用 。 


要 实现 涵盖 音频 和 视频 的 电话 会 议 等 完善 、 高 品质 的 RTC 应 用 ， 以 及 端 到 端的 数据 
交换 ， 需 要 浏览 器 具备 很 多 新 功能 : 音频 和 视频 处 理 能 力 、 支 持 新 应 用 API、 支 持 
好 几 种 新 网 络 协议 。 好 在 ， 浏 览 器 把 大 多 数 复杂 性 抽象 成 了 三 个 主要 API: 

















。 MediaStream: 获取 音频 和 视频 流 ，; 
。 RTCPeerConnection: 音频 和 视频 数据 通信 ; 
。 RTCDataChannel: 任意 应 用 数据 通信 。 
































全 部 功能 实现 起 来 只 需 十 几 行 JavaScript 代码 ， 任 何 Web 应 用 都 可 以 立即 支持 全 功 
能 的 电话 会 议 ， 以 及 端 到 端的 数据 交换 。 这 是 WebRTC 的 愿景 和 能 力 ! 可 是 ， 上 述 
API 只 是 冰山 一 角 : 发 信号 、 成 员 发 现 、 连 接 协商 、 安 全 性 ， 以 及 多 层 协议 ， 这 些 
还 有 更 多 组 件 的 协同 也 是 关键 。 


毫 无 疑问 ，WebRTC 的 架构 和 协议 也 决定 了 其 性 能 特点 : 连接 准备 延迟 、 协 议 
开销 ， 还 有 交付 语义 ， 只 是 其 中 一 部 分 。 事 实 上 ， 与 其 他 浏览 器 通信 机 制 不 同 ， 
WebRTC 通过 UDP 传输 数据 。 不 过 ，UDP 只 是 个 起 点 ， 为 了 实现 浏览 器 间 实 时 通 
信 ， 还 有 很 多 超出 原始 UDP 之 外 的 技术 。 本 章 我 们 就 详细 地 加 以 讨论 。 
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制定 中 的 标准 

一 webRTC 可 以 为 10 多 亿 用 户 提供 服务 最 新 的 Chrome 和 Firefox 浏览 器 
为 它们 所 有 的 用 户 提供 WebRTC 支持 ! 话 虽 如 此 ，WebRTC 标准 仍然 在 
紧张 地 制定 中 ， 包 含 浏览 器 API、 传 输 层 及 协议 。 因 此 ， 本 章 讨论 的 个 别 
API 和 协议 有 可 能 在 将 来 发 生变 化 。 























18.1 标准 和 WebRTC 的 发 展 

在 训 览 器 中 实现 实时 通信 不 可 谓 不 雄心 勃勃 ， 毕 竟 ， 这 是 Web 被 发 明 以 来 最 重大 的 
一 次 功能 增补 。WebRTC 脱 开 我 们 熟悉 的 C/S 通信 模型 ， 重 新 设计 了 浏览 器 的 网 络 
层 ， 同 时 引入 了 全 新 的 媒体 机 制 ， 而 这 对 于 有 效 处 理 音 频 和 视频 是 必需 的 。 

正 因为 如 此 ，WebRTC 架构 由 十 余 个 标准 组 成 ， 涵 盖 了 应 用 和 浏览 器 API， 以 及 很 
多 必要 的 协议 和 数据 格式 : 











。 W3C 的 Web Real-Time Communications (WEBRTC) Working Group 负责 制定 浏 
览 器 API; 

。 IETF 的 Real-Time Communication in Web-browsers (RTCWEB) 工作 组 负责 定 
义 协议 、 数 据 格式 、 安 全 及 其 他 在 浏览 器 中 实现 端 到 端 通信 必需 的 内 容 。 


WebRTC 并 不 是 一 个 孤立 的 标准 。 虽 然 它 的 目的 主要 是 实现 浏览 器 间 的 实时 通信 ， 
但 设计 它 的 时 候 也 会 考虑 已 有 通信 系统 : VOIP (Voice Over IP) 、 各 种 SIP 客户 端 ， 
甚至 PSTN (Public Switched Telephone Network， 公 共 交 换 电 话 网 )， 等 等 。 这 些 
WebRTC 标准 不 规定 任何 特定 的 互 操作 需求 或 API， 但 它们 会 尽 可 能 重用 相同 的 概 
念 和 协议 。 


























换 句 话说 ，WebRTC 不 仅 要 赋予 浏览 器 实时 通信 和 能力， 而 且 会 把 浏览 器 的 全 部 功能 
带 到 通信 行业 一 一 2012 年 产值 4.7 万 亿 ! 不 必 说 ， 这 个 步子 迈 得 很 大 ， 很 多 电信 和 巨 
头 、 企 业 及 创业 公司 都 紧 随 其 后 。WebRTC 可 远 远 不 止 是 浏览 器 的 一 个 新 API。 


18.2 ”音频 和 视频 引擎 

要 实现 电话 会 议 功能 ， 浏 览 器 必须 访问 系统 硬件 采集 音频 和 视频 。 为 此 ， 无 需 第 三 
方 插件 或 自 定义 的 驱动 ， 只 要 使 用 一 套 简 单 统一 的 API 即 可 。 可 是 ， 只 捕获 原始 音 
频 和 视频 流 还 不 够 ， 还 需要 对 它们 分 别 加 以 处 理 以 增强 品质 ， 保 证 同步 ， 而 且 要 迁 
应 不 断 变 化 的 带宽 和 客户 端 之 间 的 网 络 延 迟 调整 输出 的 比特 率 。 


接收 端的 处 理 过 程 相 反 ， 必 须 实时 解码 音频 和 视频 流 ， 并 适应 网 络 抖动 和 时 延 。 总 
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之 ,采集 及 处 理 音 频 和 视频 很 复杂 。 不 过 ， 好 消息 是 WebRTC 会 让 浏览 器 具备 功能 
完备 的 音频 和 视频 引擎 (图 18-1) ， 由 它们 替 我 们 完成 处 理 信号 等 琐碎 的 工作 。 





音频 引擎 视频 引擎 














18-1: WebRTC 的 音频 和 视频 引擎 





要 详细 介绍 音频 和 视频 引擎 ， 轻 易 就 能 再 写 一 本 书 ， 已 经 超出 本 书 讨论 范 
uw 4 。， 围 了 。 更 多 信息 ， 请 参考 ,http:Wwww.webrtc.org。 


0 








获得 的 音频 流 要 经 过 降 噪 和 回声 消除 处 理 ， 然 后 自动 通过 一 种 优化 的 罕 带 或 宽带 音 
频 编 解码 器 编码 。 关 键 在 于 ， 还 要 通过 特殊 的 错误 补偿 算法 消除 网 络 拌 动 和 丢 包 造 
成 的 损失 ， 这 是 重点 ! 视频 引擎 的 流程 与 此 类 似 ， 但 着 眼 于 影像 品质 ， 选 择 最 优 的 
压缩 和 编 解 码 方案 ， 应 用 抖动 和 丢 包 补偿 ， 等 等 。 


所 有 这 一 切 都 由 浏览 器 负责 ， 而 且 更 重要 的 是 ， 浏 览 器 会 动态 调整 其 处 理 流程 ， 以 
适应 不 断 变 化 的 音频 和 视频 流 及 网 络 条 件 。 经 过 浏览 器 这 一 系列 处 理 之 后 ，Web 应 
用 接收 到 了 优化 的 媒体 流 ， 然 后 可 以 将 其 输出 到 显示 器 和 扬声器 ， 发 送 给 另外 一 端 ， 
或 者 使 用 HTML5 的 媒体 API 进行 后 期 处 理 ! 


通过 getUserMedia 获 取 音 频 和 视频 
W3C 的 Media Capture and Streams 规范 规定 了 一 套 新 JavaScript API， 应 用 可 
以 通过 这 套 API 从 平台 取得 音频 和 视频 流 ， 并 对 它们 进行 操作 和 处 理 。 其 中 ， 
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MediaStreanm 对 象 (图 18-2) 是 实现 这 个 功能 的 主要 接口 。 





MediaStream 














图 18-2: MediaStream 中 携带 着 一 或 多 个 同步 的 Track 


。 Mediastream 对 象 包含 一 或 多 个 Track (MediastreamTrack ) 。 

。 MediaStream 中 的 多 个 Track 相互 之 间 是 同步 的 。 

输入 源 可 以 是 物理 设备 ， 如 麦克 风 、 摄 像 头 、 用 户 硬 盘 或 另 一 端 远 程 服 务 器 中 的 

文件 。 

。 MediaStrean 的 输出 可 以 被 发 送 到 一 或 多 个 目的 地 : 本 地 的 视频 或 音频 元 素 、 后 
期 处 理 的 JavaScript 代理 ， 或 者 远程 另 一 端 。 


Mediastream 对 象 表 示 一 个 实时 的 媒体 流 ， 以 便 应 用 代码 从 中 取得 数据 ， 操 作 个 别 的 
Track 和 控制 输出 。 所 有 的 音频 和 视频 处 理 ， 比 如 降 噪 、 均 衡 、 影 像 增 强 等 都 由 音 
频 和 视频 引擎 自动 完成 。 


不 过 ， 获 得 的 媒体 流 具 备 什么 特性 ， 取 决 于 输入 源 : 麦克 风 只 能 输入 音频 流 、 某 些 
网 络 摄像 头 能 拍摄 较 高 解析 度 的 视频 。 因 此 ， 在 浏览 嚣 中 请 求 视频 流 时 ， 可 以 通过 
getUserMedia() API 指定 一 系列 强制 和 可 选 的 约束 条 件 ， 以 匹配 应 用 的 需求 : 


<video autopLay></video> @ 


<script> 
var constraints = { 
audio: true, @ 


video: { © 
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mandatory: { @ 
width: { min: 320 }, 
height: { min: 180 } 


optional: [ © 
{ width: { max: 1280 }}, 
{ frameRate: 30 }, 
{ facingMode: "user" } 
] 
} 
} 


navigator .getUserMedia(constraints, gotStream, logError); @ 


function gotStream(stream) { @ 


var video = document.querySelector('video'); 
video.src = window.URL.createObjectURL(stream); 
} 
function LogError(error) { ... } 
</script> 


@ HTML 的 video 元素， 用 于 输出 
@ 指定 请 求 音频 Track 

@ 指定 请 求 视频 Track 

@ 对 视频 Track 的 强制 约束 条 件 

加 对 视频 Track 的 可 选 约束 条 件 

@ 从 浏览 器 中 请 求 音频 和 视频 流 

@ 处 理 Mediastream 对 象 的 回调 函数 


这 个 例子 示范 了 一 种 稍微 复杂 的 场景 : 在 浏览 器 中 同时 请 求 音频 和 视频 Track， 同 
时 指定 了 最 小 解析 度 和 必须 使 用 的 摄像 机 类 型 ， 以 及 针对 720p 高 清 视频 的 一 组 可 选 
约束 。getUserMedia() API 负责 获准 访问 用 户 的 麦克 风 和 摄像 机 ， 并 获取 符合 指定 
要 求 的 流 一 一 大 致 就 这 意思 吧 。 


这 里 的 API 同样 允许 应 用 操作 个 别 的 Track， 复 制 它们 ， 修 改 约束 ， 等 等 。 另 外 ， 
取得 流 之 后 ， 还 可 以 将 它们 提供 给 其 他 浏览 器 API: 








。 通过 Web Audio API 在 浏览 器 中 处 理 音频 ; 
。 通过 Canvas API 采集 个 别 视频 帧 并 加 以 处 理 ， 
。 通过 CSS3 和 WebGL API 为 输出 的 流 应 用 各 种 2D/3D 特效 。 





























长 话 短 说 ，getUserMedia() 就 是 从 底层 平台 取得 音频 和 视频 流 的 简单 API。 得 到 的 
媒体 都 经 过 了 WebRTC 音频 和 视频 引擎 的 自动 优化 、 编 码 、 解 码 ， 然 后 可 以 输出 到 
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各 种 目的 地 。 这 样 ， 我 们 完成 了 实时 电话 会 议 应 用 的 一 半 ， 剩 下 的 就 是 把 数据 传输 
给 另 一 端 了 1 
心 要 了 解 Media Capture and Streams 还 提供 了 哪些 API， 请 参考 W3C 官方 标 


PFA 。 准 : http://www.w3.org/TR/mediacapture-streams/。 











音频 (Opus) 与 视频 (VP8) 比特 率 


在 通过 浏览 器 请 求 音 频 和 视频 时 ， 要 注意 流 的 大 小 和 品质 。 虽 然 硬件 有 时 候 可 以 
捕获 到 高 质量 的 流 ， 但 CPU 和 带宽 必须 跟 得 上 | 当前 的 WebRTC 实现 使 用 Opus 
和 VP8 编 解 码 器 : 
。 Opus 编 解码 器 用 于 音频 ， 支 持 固 定 和 可 变 的 比特 率 编 码 ， 适 合 的 带宽 范围 为 
6~510 Kbits。 这 个 编 解 码 器 可 以 无 颖 切换 ， 以 适应 不 同 的 带宽 。 
。 VP8 编 解码 器 用 于 视频 编码 ， 要 求 带 宽 为 100~2000+ Kbits， 比 特 率 取决 于 
流 的 品质 : 
+ 720p,30 FPS: 1.0~2.0 Mbit/s 
+ 360p, 30 FPS: 0.5~1.0 Mbit/s 
+ 180p, 30 FPS: 0.1~0.5 Mbit/s 
因此 ， 单 方 高 清音 视频 流 最 多 需要 2.5 Mbit/s 以 上 的 带宽 。 如 果 是 多 方 视频 通话 ， 
那么 考虑 到 要 人 额外 占用 带宽 、CPU 和 GPU 及 内 存 资源 ， 就 必须 降低 品质 。 











18.3 ”实时 网 络 传输 


实时 通信 讲究 的 就 是 及 时 、 当 下 。 因 此 ， 处 理 音频 和 视频 流 的 应 用 一 定 要 补偿 间歇 
性 的 丢 包 : 音频 和 视频 编 解 码 器 可 以 填充 小 的 数据 空白 ， 通 常 对 输出 品质 的 影响 也 
很 小 。 类 似 地 ， 应 用 必须 实现 自己 的 逻辑 ， 以 便 因 传输 其 他 应 用 数据 而 丢 包 或 延迟 
时 快速 恢复 。 及 时 和 低 延 迟 比 可 靠 更 重要 。 


二 所 


4 音频 和 视频 流 还 要 适应 人 类 大 脑 的 特点 。 换 句 话 说 ， 我 们 的 大 脑 非 常 擅长 
A 
Me 

4 














。 填 充 空白 ， 但 对 延迟 非常 敏感 。 忽 长 包 短 的 几 次 延迟 就 会 让 人 觉得 “肯定 
是 哪里 出 问题 了 ”， 而 从 中 间 有 删除 一 些 采样 数据 ， 却 很 可 能 不 会 引起 我 们 大 
脑 的 注意 ! 











正 因为 及 时 性 的 要 求 高 于 可 靠 性 ， 所 以 UDP 协议 才 更 适合 用 于 传输 实时 数据 。TCP 
适合 传输 可 靠 的 、 有 序 的 数据 流 ， 如 果 中 间 有 丢 包 ，TCP 就 会 缓冲 后 续 所 有 包 ， 等 
待 重 传 ， 然 后 再 严格 按照 次 序 交 给 应 用 。 相 对 来 说 ，UDP 则 提供 下 列 “ 不 服务 ”: 
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不 确认 ， 不 重 传 ， 无 超时 。 
。 不 保证 交付 顺序 

不 设置 包 序 号 ， 不 重 排 ， 不 会 发 生 队 首 阻 塞 。 
。 不 跟踪 连接 状态 

不 必 建 立 连 接 或 重启 状态 机 。 
。 不 需要 拥塞 控制 

不 内 置 客户 端 或 网 络 反馈 机 制 。 





中 进一步 讨论 之 前 ， 建 议 大 家 回顾 一 下 第 3 章 ， 特 别 是 3.1 节 “ 无 协议 服 
4 4、 务 "， 以 重 温 UDP 的 工作 原理 。 

DSN 
UDP 不 保证 数据 的 可 靠 性 或 者 次 序 ， 只 要 有 人 包 到 来 就 直接 交 给 应 用 。 事 实 上 ,UDP 
只 是 对 IP 层 的 简单 封装 。 


WebRTC 就 使 用 UDP 作为 传输 层 协议 : 低 延 迟 和 及 时 性 才 是 关键 。 因 此 ， 只 要 打 

开 音 频 、 视 频 ， 应 用 就 会 发 送 UDP 包 ， 然 后 就 搞定 了 ? 还 没 那么 简单 。 我 们 还 是 需 

| 穿 透 层 层 NAT 和 防火 墙 ， 为 每 个 流 协 商 参 数 ， 对 用 户 数据 进行 加 密 ， 
现 拥 塞 和 流量 控制 ， 等 等 。 


UDP 是 浏览 器 实时 通信 的 基础 ， 但 要 完全 达到 WebRTC 的 要 求 ， 浏 览 器 还 需要 位 
于 其 上 的 大 量 协议 和 服务 的 支持 (图 18-3)。 








HTTP 1.x/2.0 


网 络 层 (IP) 














18-3: WebRTC 的 协议 分 层 
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。 ICE， 即 Interactive Connectivity Establishment (RFC 5245 ) 
，，STUN， 即 Session Traversal Utilities for NAT (RFC 5389 ) 
+ TURN, B] Traversal Using Relays around NAT (RFC 5766 ) 

。 SDP, BN Session Description Protocol (RFC 4566) 

。 DTLS， 即 Datagram Transport Layer Security (RFC 6347) 

。 SCTP, HB] Stream Control Transport Protocol (RFC 4960) 

。 SRTP, BN Secure Real-Time Transport Protocol (RFC 3711) 


ICE、STUN 和 TURN 是 通过 UDP 建立 并 维护 端 到 端 连接 所 必需 的 。DTLS 用 于 保 
障 传输 数据 的 安全 ， 毕 竟 加 密 是 WebRTC 强制 的 功能 。 最 后 ，SCTP 和 SRTP 属于 
应 用 层 协议 ， 用 于 在 UDP 之 上 提供 不 同 流 的 多 路 复 用 、 拥 塞 和 流量 控制 ， 以 及 部 分 
可 靠 的 交付 和 其 他 服务 。 


没 错 ， 这 么 多 层 是 有 点 复杂 ， 但 为 了 更 好 地 理解 端 到 端 通信 的 性 能 ， 我 们 还 必须 先 
弄 清 楚 这 些 层 的 作用 。 而 这 正 是 本 章 后 面 所 要 讨论 的 重点 。 好 吧 ， 开 始 。 





























不 要 忘 了 SDP ! 后 面 会 提 到 ，SDP 是 一 种 数据 格式 ， 用 于 端 到 端 连 接 时 协 
心 。 商 参数 。 可 是 ，SDP 的 “提议 与 应 答 ”(Offer/Answer) 并 不 在 系统 内 部 ， 
”所 以 前 面 图 中 才 没 有 体现 它 。 




















RTCPeerConnection API 简 介 


尽管 用 于 建立 和 维护 端 到 端 连接 涉及 的 协议 很 多 ， 但 浏览 器 中 的 应 用 API 相对 简 
单 。 其 中 ，RTCPeerConnection 接口 (图 18-4) 就 负责 维护 每 一 个 端 到 端 连接 的 完整 
生命 周期 : 


。 RTCPeerConnection 管理 穿越 NAT 的 完整 ICE 工作 流 ， 

。 RTCPeerConnection 发 送 自动 (STUN) 持久 化 信和 号; 

。 RTCPeerConnection 跟踪 本 地 流 ，; 

。 RTCPeerConnection 跟踪 远程 流 ; 

。 RTCPeerConnection 按 需 触发 自动 流 协 商 ; 

。 RTCPeerConnection 提供 必要 的 API， 以 生成 连接 提议 ， 接 收 应答 ， 允 许 我 们 查询 
连接 的 当前 状态 ， 等 等 。 




















J 

















18-4:; RTCPeerConnection API 


简单 地 说 ，RTCPeerConnection 把 所 有 连接 设置 、 管 理 和 状态 都 封装 在 了 一 个 接口 
中 。 不 过 ， 在 深入 探讨 RTCPeerConnection API 的 每 个 设置 项 之 前 ， 必 须 首 先 搞 明白 
发 信号 和 协商 、 提 议 与 应 答 工作 流 ， 以 及 ICE 穿越。 下 面 我 们 就 逐个 介绍 。 





DataChannel 


DataChannel API 用 于 实现 总 到 痛 之 间 的 任意 应 用 数据 交换 ， 类 似 于 WebSocket， 
但 却 是 端 到 端 交 换 。 而且， 底层 传输 机 制 的 属性 也 是 可 定制 的 。 每 个 DataChannel 
可 以 经 过 配置 提供 以 下 特性 : 


。 发 送 消息 可 靠 或 部 分 可 靠 的 交付 ; 

不 可 靠 的 乱 序 交付 等 同 于 原始 UDP， 即 消息 可 能 到 达 ， 也 可 能 不 到 达 ， 而且 到 达 
次 序 也 没有 保证 。 然 而 ， 我 们 可 以 让 信道 “部 分 可 靠 ”， 也 就 是 设 定 重 传 的 最 大 次 
数 或 时 间 限 制 : WebRTC 的 各 个 层 负 责 处 理 确认 和 超时 。 

信道 的 每 一 项 配置 都 有 自己 的 性 能 特点 和 局 限 ， 稍 后 还 会 介绍 。 我 们 继续 。 
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18.4 建立 端 到 端的 连接 

与 打开 XHR、EventSource 或 新 WebSocket 会 话 相 比 ， 初 始 化 一 个 端 到 端的 连接 所 
做 的 事 要 多 很 多 : 前 三 者 依赖 于 定义 完善 的 HTTP 握手 机 制 协商 连接 参数 ， 而 且 它 
们 都 假定 客户 端 可 以 访问 到 目标 服务 器 〈 比 如， 服务 器 具有 公开 的 可 以 路 由 到 的 IP 
地 址 ， 或 者 客户 端 和 服务 器 本 身 都 在 一 个 内 部 网 中 ) 。 

相对 而 言 ，WebRTC 两 端 则 很 可 能 分 别 位 于 自己 的 私有 网 络 中 ， 而 且 中 间 还 隔 着 一 
或 多 层 NAT。 结 果 ， 任 何 一 方 也 不 能 直接 访问 对 方 。 为 发 起 会 话 ， 首 先 必须 找到 两 
端的 候选 了 了 和 端口 (candidate)， 穿 越 NAT， 然 后 检查 连接 ， 以 期 找到 可 用 路 径 。 
而 即便 到 了 这 一 步 ， 也 不 能 保证 成 功 。 


二 六 











I 回顾 3.2 节 “UDP 与 网 络 地 址 转换 器 ”和 3.2.2 节 “NAT 穿 透 "， 以 了 解 
人 SS NAT 对 UDP 及 端 到 端 通信 的 巨大 影响 。 
“4 


不 过 ， 尽 管 NAT 穿越 必须 处 理 ， 但 我 们 了 臣 怕 还 是 有 点 性 急 了 。 在 打开 到 服务 器 的 
HTTP 连接 时 ， 我 们 心里 会 假设 服务 器 会 监听 握手 。 服 务 器 当然 可 能 拒绝 ， 但 不 管 
怎样 它 会 一 直 监 听 新 连接 。 不 幸 的 是 ， 我 们 对 远 端 没 办 法 作 这 种 假设 : 远 端 可 能 不 
在 线 或 根本 访问 不 到 ， 亦 或 根本 就 不 想 与 其 他 端 建立 连接 。 


因此 ， 要 想 成 功 地 建立 端 到 端的 连接 ， 必 须 首 先 解决 另外 几 个 问题 : 


(1) 必须 通知 另 一 端 我 们 想 打开 一 个 端 到 端的 连接 ， 以 便 它 知道 开始 监听 到 来 的 分 组 ; 
(2) 必须 找 出 两 端 之 间 建 立 连 接 所 需 的 路 由 线路 ， 并 在 两 端 传播 这 个 信息 ， 
(3) 必须 交换 有 关 媒 介 和 数据 流 的 必要 信息 ， 比 如 协议 、 编 码 ， 等 等 。 


好 消息 是 ，WebRTC 为 我 们 解决 了 其 中 一 个 问题 : 内 置 的 ICE 协议 会 执行 必要 的 路 
由 和 连接 检查 。 然 而 ， 发 送 通知 〈 信 号 ) 和 协商 会 话 仍然 要 由 应 用 负责 。 


18.4.1 发 信号 和 协商 会 话 

在 检查 连接 或 协商 会 话 之 前 ， 必 须知 道 能 否 将 信息 发 送 到 另 一 个 端 ， 以 及 另 一 端 
是 否 愿 意 建立 连接 。 为 此 ， 我 们 必须 发 出 一 个 信号 ， 而 另 一 端 必 须 返 回应 答 (图 
18-5)。 但 这 样 我 们 就 会 面临 一 个 困境 : 如 果 另 一 端 没 有 监听 数据 包 ， 那 我 们 向 谁 表 
达 自 己 的 意图 呢 ? 最 低 限 度 ， 我 们 需要 一 个 共享 的 发 信 通 道 。 
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发 信 通 首 

















18-5: 共享 的 发 信 通 


WebRTC 把 发 送信 号 和 协议 的 选择 交 给 了 应 用 ， 而 标准 有 意 未 给 发 送信 号 的 过 程 提 
供 建议 或 实现 。 为 什么 ? 这 样 可 以 让 现 有 通信 基础 设施 中 的 其 他 发 信 协 议 能 够 互 操 
作 ， 包 括 如 几 个 协议 。 


。 SIP (Session Initiation Protocol， 会 话 初 始 协议 ) 
应 用 级 发 信 协 议 ， 广 泛 用 于 通过 IP 实现 的 语音 通话 (VoIP) 和 视频 会 议 





。 Jingle 
XMPP 协议 的 发 信 扩 展 ， 用 于 通过 IP 实现 的 语音 通话 (VoIP) 和 视频 会 议 的 会 
话 控 制 。 

。 ISUP (ISDN User Part，ISDN 用 户 部 分 ) 
全 球 各 大 公共 电话 交换 网 中 用 于 启动 电话 呼叫 的 发 信 协 议 。 


过 忆 

















: 在 房间 一 头 冲 另 一 头 喊 话 ， 也 算是 利用 了 “发 信 信 道 "。 当 然 ， 你 的 通信 对 
心 。 象 必须 能 听 到 才 行 ! 选择 什么 发 信 媒 介 和 协议 完全 是 应 用 说 了 算 。 


WebRTC 应 用 可 以 选择 已 有 的 任何 发 信 协 议和 网 关 (图 18-6) ， 利 用 既 有 通信 系统 
协商 一 次 通话 或 视频 会 议 。 比 如 ， 通 过 PSTN 客户 端 拨 一 通 “ 电 话 ”! 此 外 ， 应 用 
还 可 以 用 自 定义 的 协议 实现 自己 的 发 信服 务 。 



































SIP/Jingle/ISUP ; 定义 发 信 ' 多 网 关 发 信 











发 信 网 关 网 关 服务 











18-6: SIP、Jingle、ISUP 和 自 定 义 发 信 网 关 
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发 信服 务 器 可 以 作为 已 有 通信 网 络 的 网 关 ， 此 时 由 网 络 负责 将 连接 提议 发 送 给 目标 
端 ， 然 后 再 将 应 答 返回 给 WebRTC 客户 端 ， 以 初始 化 信息 交换 。 而 应 用 也 可 以 使 用 
自己 的 自 定义 发 信 信 道 ， 可 能 由 一 或 多 台 服 务 器 和 一 个 自 定义 通信 协议 构成 : 如 果 
两 端 都 连 到 了 同一 个 发 信服 务 ， 那 这 个 服务 就 可 以 为 它们 传递 消息 。 














5 


Skype 是 使 用 自 定义 发 信 系统 中 的 一 个 典型 示例 ， 音频 和 视频 通信 是 端 到 
4 4 ， 端 的 ， 而 Skype 用 户 必须 连接 到 Skype 的 发 信服 务 器 ， 该 服务 器 使 用 自己 
必 ， 专 有 的 协议 辅助 实现 端 到 端的 连接 。 














选择 发 信服 务 
WebRTC 可 以 让 我 们 实现 端 到 端的 通信 ， 但 每 个 WebRTC 应 用 都 需要 一 个 发 信服 
务 器 才能 完成 协商 并 建立 连接 。 那 该 怎么 办 ? 
目前 ， 可 以 与 WebRTC 互 操作 的 通信 网 关 越 来 越 多 。 比 如 Asterisk 就 是 这 么 一 个 
流行 、 免 费 、 开 源 的 框架 ,被 全 球 很 多 私人 公司 和 大 型 运营 商 采 用 ， 以 实现 他 们 
的 无 线 电 通信 。 对 我 们 来 说 ，Asterisk 有 一 个 WebSocket 模块 ， 该 模块 支持 将 SIP 
作为 发 信 协 议 : 浏览 器 建立 到 Asterisk 网 关 的 WebSocket 连接 ， 然 后 两 者 通过 交 
换 SIP 消息 来 协商 会 话 ! 
此 外 ， 如 果 不 需要 与 其 他 网 络 互 操作 ， 那 么 实现 并 部 署 自 定 义 的 发 信 网 络 对 应 用 
而 言 也 不 难 。 比 如， 一 个 网 站 可 以 为 用 户 提 供 端 到 端的 音频 、 视 频 和 数据 交换 服 
务 ， 而 该 网 站 会 跟踪 所 有 已 经 登录 的 用 户 ， 所 以 它 可 以 对 所 有 在 线 用 户 打 开发 信 
连接 。 然 后 ， 当 两 个 用 户 想 要 建立 端 到 端的 会 话 时 ， 网 站 的 服务 器 就 可 以 为 两 个 
客户 话 “ 鸿 雁 传 书 ”。 


选择 什么 发 信和 网 关 要 视 具 体 情况 而 定 ， 了 取决 于 应 用 的 自身 需求 。 不 过 ， 在 考虑 自 
定义 之 前 ， 有 必要 先 调 研一 下 市 面 上 有 哪些 开源 或 商业 的 服务 可 用 。 当 然 ， 一 定 
要 密切 关注 底层 的 发 信 协 议 ， 因 为 协议 很 可 能 严重 影响 发 信 通 道 的 延迟 和 客户 和 闹 
与 服务 器 的 开销 ; 参见 14.4 节 “ 应 用 API 与 协议 ”。 











18.4.2 会 话 描述 协议 (SDP) 
假设 应 用 实现 了 共享 的 发 信 通 道 ， 那 接 下 来 就 可 以 执行 发 起 WebRTC 连接 的 初始 
步 又: 


var signalingChannel = new SignalingChannel(); © 
var pc = new RTCPeerConnection({}); © 


navigator .getUserMedia({ "audio": true }, gotSstream, logError); © 


function gotStream(stream) { 
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pc.addstream(stream); @ 


pc.createoffer(function(offer) { © 
pc.setLocalDescription(offer); @ 
signalingChannel.send(offer .sdp); @ 


2 
} 


function LogError() { ... } 


@ 初始 化 共享 的 发 信 通 道 

@ 初始 化 RTCPeerConnection 对 象 

向 浏览 器 请 求 音频 流 

@ 通过 RTCPeerConnection 注册 本 地 音频 流 
@ 创建 端 到 端 连接 的 SDP (提议 ) 描述 

@ 以 生成 的 SDP 作为 端 到 端 连接 的 本 地 描述 
@ 通过 发 信和 通道 向 远 端 发 送 SDP 提议 





























本 书 示例 将 使 用 不 带 前 级 的 API， 也 就 是 W3C 标准 中 定义 的 形式 。 实 际 
心 Es 在 所 有 浏览 器 都 最 终 实现 该 标准 之 前 ， 你 需要 根据 自己 的 浏览 器 调整 
全 示例 代 码 。 








WebRTC 使 用 SDP (Session Description Protocol， 会 话 描述 协议 ) 描述 端 到 端 连接 
的 参数 。SDP 不 包含 媒体 本 身 的 任何 信息 ， 仅 用 于 描述 “会 话 状 况 ”， 表 现 为 一 系 
列 的 连接 属性 : 要 交换 的 媒体 类 型 (音频 、 视 频 及 应 用 数据 )、 网 络 传输 协议 、 使 用 
的 编 解 码 器 及 其 设置 、 带 宽 及 其 他 元 数据 。 


在 前 面 的 例子 中 ， 通 过 RTCPeerConnection 对 象 注 册 了 本 地 音频 流 之 后 ， 我 们 调用 
createoffer() 生成 有 关 会 话 的 SDP 描述 。 生 成 的 SDP 包含 什么 信息 ?下 面 我 们 就 
来 看 一 看 : 

Ga 省 略 的 内 容 ……) 


m=audio 1 RTP/SAVPF 111 ... © 


a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level 
a=candidate:1862263974 1 udp 2113937151 192.168.1.73 60834 typ host ... © 


a=mid:audio 
a=rtpmap:111 opus/48000/2 © 


a=fmtp:111 minptime=10 
人 省 略 的 内 容 …… ) 


@ 带 反 馈 的 安全 音频 信息 
@ 媒体 流 的 候选 了 了、 端口 及 协议 
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@ Opus 编 解 码 器 及 基本 配置 


SDP 是 一 个 基于 文本 的 简单 协议 (RFC 4568) ， 用 于 描述 会 话 属性 。 在 前 面 的 例子 
中 ， 我 们 通过 它 描 述 的 是 采集 的 音频 流 。 好 消息 是 ，WebRTC 应 用 不 必 直 接 处 理 
SDP。JSEP ( JavaScript Session Establishment Protocol ，JavaScript 会 话 建立 协议 ) 
定义 了 对 RTCPeerConnection 对 象 几 个 方法 的 简单 调用 ， 就 把 SDP 所 有 的 内 部 工作 
全 都 隐藏 了 起 来 。 


生成 提议 之 后 ， 就 可 以 通过 发 信 通 道 将 它 发 送 给 远 端 。 同 样 ， 如 何 编码 SDP 取决 于 
应 用 : SDP 字符 串 可 以 像 前 面 那 样 〈 作 为 简单 的 文本 blob) 直接 传输 ， 也 可 以 将 它 
编码 成 任意 格式 后 再 传输 。 咽 ，Jingle 协议 提供 了 从 SDP 到 XMPP (XML ) 格式 的 
映射 。 


要 建立 端 到 端的 连接 ， 两 端 都 必须 遵循 一 个 对 称 的 工作 流 (图 18-7) ， 以 交换 各 自 
音频 、 视 频 及 其 他 数据 流 的 SDP 描述 。 





























setLocalDescription setRemoteDescription 











setRemoteDescription setLocalDescription 





18-7: 两 端 之 间 的 SDP 提议 / 应 答 交 换 


(1) 连接 发 起 者 ( 张 三 ) 通过 自己 的 本 地 RTCPeerConnection 对 象 注 册 一 或 多 个 流 ， 
创建 提议 ， 并 将 其 设置 为 会 话 的 “本 地 描述 ”。 

(2) 然后 ， 张 三 把 生成 的 会 话 提议 发 送 给 另 一 端 ( 李 四 )。 

(3) 李 四 收 到 提议 后 ， 将 张 三 的 摘 述 设置 为 会 话 的 “远程 描述 >”， 使 用 他 自己 的 
RTCPeerConnection 对 象 注册 自己 的 流 ， 生 成 应 答 的 SDP 描述 ， 并 将 其 设置 为 会 
话 的 “本 地 描述 ”。 

(4) 然后 ， 李 四 把 生成 的 会 话 应 答 回 传 给 张 三 。 

(5) 张 三 接 到 李 四 的 SDP 应 答 后 ， 再 将 这 个 应 答 设置 为 原始 会 话 的 “远程 描述 ”。 

这 样 ， 在 通过 发 信和 通道 交换 SDP 会 话 描 述 后 ， 双 方 就 交换 了 经 过 协商 的 流 类 型 及 相 

应 设置 。 然 后 差不多 马上 就 可 以 开始 端 到 端的 通信 了 ! 不 过 ， 在 此 之 前 还 必须 注意 

一 个 细节 ， 那 就 是 连接 检查 和 NAT 穿越 。 
































284 | 第 18 章 


18.4.3 ”交互 连接 建立 (ICE) 
按照 规范 ， 为 建立 端 到 端的 连接 ， 两 端 必 须 之 间 必 须 能 收发 数据 包 。 说 起 来 很 简单 ， 
但 由 于 端 与 端 之 间 往 往 有 很 多 层 防 火 墙 和 NAT 设备 阻隔 (参见 3.2 节 “UDP 与 网 
络 地 址 转换 器 ”)， 真 正 实现 起 来 并 不 容易 。 


首先 ， 我 们 先 看 一 看 最 简单 的 情况 ， 即 两 端 位 于 同一 个 内 部 网 中 ， 而 且 它们 之 间 不 
存在 防火 墙 或 NAT 设备 。 此 时 ， 要 建立 连接 ， 两 端 只 要 查询 操作 系统 获知 IP 地 址 
(如 果 有 多 块 网 卡 ， 就 需要 多 个 IP 地 址 )， 将 IP 地 址 加 端口 号 追加 到 生成 的 SDP 字 
符 串 中 ， 再 把 SDP 转发 给 另 一 端 即 可 。SDP 交换 一 完成 ， 两 端 就 可 以 发 起 直接 的 端 
到 端 连接 。 

















前 面 那个 SDP 示例 展示 的 就 是 刚才 提 到 的 情况 : 其 中 a=candidate 那 一 行 
心 列 出 的 就 是 一 个 私有 耳 地 址 〈192.168.x.x) ， 供 相应 端 发 起 会 话 (参见 3.2 
节 中 的 “保留 的 私有 网 络 地 址 范围 ”)。 








目前 来 看 没什么 问题 。 可 是 ， 如 果 其 中 一 端 或 者 干脆 两 端 分 别 位 于 明显 不 同 的 私有 
网 络 中 又 会 怎么 样 呢 ?” 当 然 还 是 重复 前 述 工 作 流 ， 找 到 并 把 每 一 端的 了 全 地 址 能 入 
SDP， 但 端 到 端的 连接 很 明显 无 法 连接 成 功 ! 我 们 需要 的 是 一 条 连接 两 端的 公共 路 
由 线路 。 好 在 ，WebRTC 框架 可 以 代替 我 们 处 理 大 部 分 复杂 工作 : 








。 每 个 RTCPeerConnection 连接 对 象 都 包含 一 个 “ICE 代理 ”， 
。 ICE 代理 负责 收集 IP 地址 和 端口 (candidate) ; 

。 ICE 代理 负责 执行 两 端的 连接 检查 ， 

。 ICE 代理 负责 发 送 连 接 持久 化 信息 。 


设置 好 会 话 描述 后 (无论 本 地 还 是 远程 )， 本 地 ICE 代理 会 自动 开始 发 现 本 地 端 所 
有 可 能 的 候选 IP 和 端口 的 进程 : 


(1)ICE 代理 向 操作 系统 查询 本 地 IP 地址; 

(2) 如 果 有 配置 ，ICE 代理 会 查询 外 部 STUN 服务 器 ， 以 取得 本 地 端的 公共 IP 和 端 
口号 ; 

(3) 如 果 有 配置 ，ICE 代理 会 将 TURN 服务 器 追加 为 最 后 一 个 候选 项 ， 假 如 端 到 端的 
连接 失败 ， 数 据 将 通过 指定 的 中 间 设 备 转发 。 





如 果 有 人 问 过 你 :“ 我 的 公共 也 地址 是 多 少 ? ”你 作 了 回答 ， 那 你 实际 

心 4 、 上 就 完成 了 一 次 手工 的 “STUN 查找 "。STUN 协议 允许 浏览 器 了 解 自己 

个 ， 是 否 位 于 一 个 NAT 后面， 并 发 现 自己 的 公共 全 和 端口 (参见 3.2.3 节 
“STUN、 TURN 与 ICE”) 。 
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每 发 现 一 个 新 候选 项 〈 一 个 卫 加 一 个 端口 号 ) ， 代 理 就 会 自动 通过 RTCPeerConnection 
对 象 注 册 它 ， 并 通过 一 个 回调 函数 (onicecandidate) 通知 应 用 。ICE 在 完成 收集 工 
作 后 ， 也 会 再 触发 同一 个 回调 函数 ， 以 通知 应 用 。 下 面 我 们 就 来 看 一 看 ICE 在 前 面 
的 例子 中 所 扮演 的 角色 : 





var ice = {"iceServers": [ 
{"url": "stun:stun.l.google.com:19302"}, © 
{"url": "turn:user@turnserver.com", "credential": "pass"} © 


]}; 


var signalingChannel = new SignalingChannel(); 
var pc = new RTCPeerConnection(ice); 


navigator .getUserMedia({ "audio": true }, gotStream, logError); 


function gotStream(stream) { 
pc.addstream(stream); 


pc.createOffer(function(offer) { 
pc.setLocalDescription(offer); © 
]); 
} 


pc.onicecandidate = function(evt) { 
if (evt.target.iceGatheringState == "complete’) { @ 
local.createOffer(function(offer) { 
console.log("Offer with ICE candidates: 
signalingChannel.send(offer.sdp); © 
]); 


+ offer.sdp); 


// 包含 ICE 候选 项 的 提议 : 
// a=candidate:1862263974 1 udp 2113937151 192.168.1.73 60834 typ host ... 6) 
// a=candidate:2565840242 1 udp 1845501695 50.76.44.100 60834 typ srflx ... @ 
@ STUN 服务 器 ， 配 置 为 使 用 谷歌 的 公共 测试 服务 器 
@ TURN 服务 器 ， 用 于 端 到 端 连接 失败 时 转发 数据 
@ 应 用 本 地 会 话 描述 : 初始 化 ICE 收集 过 程 
@ 预订 ICE 事件 ， 监 听 ICE 收集 完成 
@ 生成 SDP 提议 〈 此 时 包含 发 现 的 ICE 候选 项 ) 
@ 本 地 端的 私有 ICE 候选 项 (192.168.1.73:60834) 
@ STUN 服务 器 返回 的 公有 ICE 候选 项 (50.76.44.100:69834) 








二 全 
前 面 的 例子 使 用 了 谷歌 的 公共 演示 STUN 服务 器 。 可 惜 的 是 ， 只 有 STUN 
心 。 还 不 够 《参见 3.2.3 市 中 的 “现实 中 的 STUN 和 TURN )， 可 能 还 需要 再 
习 ” 提供 一 个 TURN， 以 保证 那些 不 能 直接 端 到 端 连 接 的 用 户 能 够 建立 连接 
(大 约 8% ) 。 








正 像 这 个 例子 所 展示 的 ，ICE 代理 替 我 们 处 理 了 大 部 分 复杂 工作 : ICE 收集 过 
程 是 自动 触发 的 ，STUN 查找 是 在 后 台 执 行 的 ， 而 发 现 的 候选 项 也 会 自动 通过 
RTCPeerConnection 对 象 注 册 。 上 述 过 程 完 成 后 ， 我 们 可 以 生成 SDP 提议 ， 并 通过 
发 信 通 道 发送 给 另 一 端 。 另 一 端 接收 到 ICE 候选 项 后 ， 就 可 以 进行 第 二 步 一 一 建立 
端 到 端的 连接 了 : 只 要 RTCPeerConnection 对 象 设置 了 远程 会 话 描述 (包含 另 一 端 
的 一 组 候选 IP 和 端口 号 ) ，ICE 代理 就 会 执行 连接 检查 (图 18-8) ， 以 确定 能 否 抵达 
另 一 端 。 























Source Destination |Protocol|Info 站 
38.125.106.89 192.168.1.73 STUN Binding Request user: 9+RtS5GkswWklB4dcv:fQILDgqsy+SsNQFLp 0 
192.168.1.73 38.125.106.89 STUN Binding Success Response XOR-MAPPED-ADDRESS: 38.125.106.89:50901 下 


|》Frame 17: 106 bytes on wire (848 bits), 106 bytes captured (848 bits) on lnterface 0 
b Ethernet II, Src: Apple ef:36:01 (7c:dl:c3:ef:36:01), Dst: AsustekC 23:05:c8 (08:60:6e:23:05:c8) 
bP Internet Protocol Version 4, Src: 192.168.1.73 (192.168.1.73), Dst: 38.125.106.89 (38.125.106.89) 
bP User Datagram Protocol, Src Port: 51808 (51808), Dst Port: 50901 (50901) 
Session Traversal Utilities for NAT 
[Request In: 16] 
[Time: 0.003734000 seconds] 
Db Message Type: Ox0101 (Binding Success Response) 
Message Length: 44 
Message Cookie: 2112a442 
Message Transaction ID: 766e55535854774e6e4a6b54 
Attributes 
bP XOR- MAPPED- ADDRESS: 38.125.106.89:50901 
Db MESSAGE-INTEGRITY 
bP FINGERPRINT 


18-8: WireShark 中 端 到 端 STUN 绑 定 请 求 与 响应 的 截图 


ICE 代理 发 送 消 息 (STUN 绑 定 请 求 ) ， 另 一 端 接收 之 后 必须 以 一 个 成 功 的 STUN 响 
应 确认 。 如 果 这 个 过 程 完成 ， 那 么 就 代表 着 有 了 一 条 端 到 端 连 接 的 路 由 线路 ! 相反 ， 
如 果 所 有 候选 项 都 绑 定 失败 ， 要 么 将 RTCPeerConnection 标记 为 失败 ， 要 么 回 退 到 
靠 TURN 转发 服务 器 建立 连接 。 











a 


ICE 代理 自动 确定 连接 检查 时 候选 项 的 次 序 和 优先 级 : 首先 检查 本 地 IP 地 
4 4 、 址 ， 然 后 是 公共 IP， 最 后 才 检查 TURN。 建 立 连接 后 ，ICE 代理 周期 性 地 
全 向 另 一 端 发 送 STUN 请 求 ， 以 此 保证 连接 的 持久 化 。 

















好 麻烦 ! 正如 本 节 开 头 说 的 ， 初 始 化 端 到 端的 连接 请 求 ， 比 打开 XHR、EventSource 
或 新 WebSocket 会 话 要 麻烦 得 多 。 好 在 ， 大 部 分 工作 都 有 浏 览 器 赫 我 们 干 。 可 是 ， 
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考虑 到 性 能 ， 我 们 也 必须 明白 ， 在 实际 发 送 数据 之 前 ， 可 能 会 经 历 从 STUN 服务 器 
到 通信 端 之 间 的 很 多 次 往返 一 一 当然 ， 前 提 是 ICE 协商 成 功 ! 





18.4.4 ” 增 量 提供 (Trickle ICE) 

ICE 收集 过 程 决 非 瞬间 就 能 完成 的 : 取得 本 地 IP 地 址 很 快 ， 但 查询 STUN 服务 器 
需要 经 过 到 外 部 服务 器 的 往返 ， 然 后 还 有 另 一 次 端 到 端的 STUN 连接 检查 。Trickle 
ICE 是 对 ICE 协议 的 扩展 ， 用 意 在 于 实现 端 与 端 之 间 的 增 量 收集 和 连接 检查 。 这 个 
用 意 其 实 很 简单 : 


。 两 端 交换 没有 ICE 候选 项 的 SPD 提议 ; 
。 发 现 ICE 候选 项 之 后 ， 通 过 发 信 通 道 发 送 到 另 一 端 ; 
。 新 候选 描述 一 就 纤 ， 立 即 执行 ICE 连接 检查 。 


简 言 之 ， 就 是 不 等 到 ICE 收集 过 程 完成 ， 而 是 依靠 发 信 通 道 向 另 一 端 递 增 地 交付 更 
新 ， 从 而 加 快 协商 。 相 应 的 WebRTC 实现 当然 也 很 简单 : 


var ice = {"iceServers": [ 
{"url": "stun:stun.l.google.com:19302"}, 
{"url": "turn:user@turnserver.com", "credential": "pass"} 


]}; 


var pc = new RTCPeerConnection(ice); 
navigator .getUserMedia({ "audio": true }, gotStream, logError); 


function gotStream(stream) { 
pc.addstream(stream); 


pc.createOffer(function(offer) { 
pc.setLocalDescription(offer); 
signalingChannel.send(offer.sdp); © 
]); 
} 


pc.onicecandidate = function(evt) { 
if (evt.candidate) { 
signalingChannel.send(evt.candidate); @ 
} 
} 


signalingChannel.onmessage = function(msg) { 
if (msg.candidate) { 
pc.addIceCandidate(msg.candidate); © 
} 
} 


@ 发 送 不 包含 ICE 候选 项 的 SDP 提议 
@ 本 地 ICE 代理 发 现 一 个 ICE 候选 项 后 就 立即 发 送 
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全 注册 远程 ICE 候选 项 并 开始 连接 检查 


Trickle ICE 导致 发 信 通 道 的 流量 增加 ， 但 可 以 显著 减少 初始 化 端 到 端 连接 的 时 间 。 
为 此 ， 所 有 WebRTC 应 用 都 应 该 考虑 这 一 点 尽快 发 送 提议 ， 然 后 随 着 发 现 依次 发 
送 ICE 候选 项 。 


18.4.5 ”跟踪 ICE 收 集 和 连接 状态 


内 置 的 ICE 框架 负责 候选 项 发 现 、 连 接 检查 、 持 久 化 ， 等 等 。 如 果 一 切 顺 利 ， 那 么 所 
有 这 些 工作 对 应 用 而 言 都 是 不 可 见 的 : 我 们 要 做 的 只 是 在 初始 化 RTCPeerConnection 
对 象 时 指定 STUN 和 TURN 服务 器 。 可 是 ， 并 非 所 有 连接 都 能 成 功 ， 此 时 隔离 和 解 
决 问题 就 很 重要 了 。 为 此 ， 我 们 可 以 查询 ICE 代理 状态 并 预订 其 通知 : 








var ice = {"iceServers": [ 
{"url": "stun:stun.l.google.com:19302"}, 
{"url": "turn:user@turnserver.com", "credential": "pass"} 


]}; 
var pc = new RTCPeerConnection(ice); 
LogStatus("ICE gathering state: " + pc.iceGatheringstate); © 


pc.onicecandidate = function(evt) { 名 
logStatus("ICE gathering state change: " + evt.target.iceGatheringState); 


} 
LogStatus("ICE connection state: " + pc.iceConnectionstate); © 
pc.oniceconnectionstatechange = function(evt) { @ 
logStatus("ICE connection state change: " + evt.target.iceConnectionState); 
让 
@ 记录 当前 ICE 收集 状态 
@ 预订 ICE 收集 事件 


加 记录 当前 ICE 连接 状态 

@ 预订 ICE 连接 状态 事件 

顾名思义 ，iceGatheringstate 属性 中 保存 的 是 本 地 端 候选 项 的 收集 状态 。 这 个 属性 
有 3 个 可 能 的 值 。 


。 new: 对 象 刚刚 创建 ， 还 没有 连 网 
。 gathering: ICE 代理 正在 收集 本 地 候选 项 。 
。 complete: ICE 代理 收集 过 程 完成 。 


同样 可 以 顾名思义 ，iceCconnectionState 属性 中 保存 着 端 到 端的 连接 状态 (图 18-9) 。 
这 个 属性 有 7 个 可 能 的 值 。 
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。 new: ICE 代理 正在 收集 候选 项 且 /或 正在 等 待 远程 候选 项 的 到 来 。 

。 checking: ICE 代理 至 少 已 经 收 到 来 自 一 个 组 件 的 远程 候选 项 ， 而 且 正 在 检查 候 
选项 ， 但 尚未 发 现 连接 除了 检查 之 外 ， 可 能 仍然 在 收集 。 

。 connected: ICE 代理 已 经 找到 一 条 通过 所 有 组 件 的 可 用 连接 ， 但 仍 在 检查 其 他 候 
选项 ， 以 确定 是 否 存 在 更 好 的 连接 ; 此 时 仍 有 可 能 还 在 收集 。 

。 completed: ICE 代理 已 经 完成 收集 和 检查 ， 而 且 发 现 了 通过 所 有 组 件 的 连接 。 

。 failed: ICE 代理 检查 完了 所 有 候选 项 ， 但 至 少 有 一 个 组 件 的 连接 失败 ， 其 他 一 
些 组 件 的 连接 可 能 成 功 了 。 

。 disconnected: 一 或 多 个 组 件 的 活动 检查 失败 ， 相 对 failed 更 严重 ， 在 不 稳定 的 
网 络 上 可 能 会 间歇 性 触发 〈 不 需要 采取 什么 行动 )。 

。 closed: ICE 代理 已 经 关闭 ， 不 再 响应 STUN 请 求 。 


恒 er eg connected completed 










































disconnected 


18-9: ICE 代理 连接 状态 和 切换 


一 个 新 的 WebRTC 会 话 可 能 需要 多 个 流 来 交付 音频 、 视 频 和 应 用 数据 。 因 此 ， 成 功 
的 连接 应 该 针对 所 有 请 求 的 流 都 能 建立 连接 。 而 且 ， 由 于 端 到 端 连接 本 身 并 不 可 靠 ， 
也 不 能 保证 连接 建立 后 会 一 直 可 用 : 连接 可 能 会 周期 性 地 在 连接 和 断 开 状态 之 间 来 
回 切换 ， 而 ICE 代理 在 重新 建立 连接 时 ， 也 会 尝试 选择 最 佳 路 径 。 

















Ya 


ve ICE 代理 最 重要 的 目标 ， 就 是 识别 端 到 端 之 间 的 可 行路 径 。 可 是 ，ICE 代 
4 



































， 理 不 会 就 此 止步 。 即 便 是 连接 已 经 建立 ，ICE 代理 也 可 能 周期 性 地 尝试 基 
”他 候选 项 ， 以 确定 其 他 路 径 的 性 能 是 否 更 好 。 
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使 用 谷歌 Chrome 浏览 器 检测 WebRTC 连接 状态 


谷歌 Chrome 为 检查 任何 WebRTC 连接 的 工作 流 和 状态 提供 了 一 个 简单 且 非 常 有 
用 的 工具 。 打 开 新 标签 页 ， 加 载 chrome://webrtc-internals。 在 这 个 标签 页 里 ， 可 以 
检查 所 有 打开 的 端 到 端 连接 (图 18-10) ， 查 看 交换 的 SDP 描述 ， 以 及 更 多 。 








从 testing123 。Talky 》 WebRTC Internals 





€ 他 名 门 chrome://webrtc-internals xz 三 





WebRTC Internals 


PeerConnection 97117-3 

https://talky.io/testing123 [stun:stun.l.google.com:19302] 
Time Event 

7/14/2013 2:30:20 PM P addStream 

7/14/2013 2:30:20 PM onRenegotiationNeeded 
7/14/2013 2:30:20 PM * setRemoteDescription 
7/14/2013 2:30:20 PM * signalingStateChange 
7/114/2013 2:30:20 PM PY onAddStream 

















18-10: 通过 chrome://webrtc-internals 查看 WebRTC 连接 状态 


Chrome 还 会 报告 每 个 流 的 一 些 统计 数据 ， 比 如 可 用 带宽 、 延 迟 、 编 码 视 频 和 音频 
的 比特 率 ， 等 等 。 即 便 你 不 开发 WebRTC 应 用 , 只 为 了 解 WebRTC 的 工作 原理 ， 
你 也 可 以 与 朋友 或 在 多 个 浏览 器 窗口 间 开 一 个 WebRTC 会 话 ， 然 后 打开 chrome:// 
webrtc-internals， 一 目 了 然 ! 确实 是 非常 难得 的 一 个 好 帮手 。 








18.4.6 ”完整 的 示例 
前 面 介绍 了 很 多 基础 知识 ， 包 括 发 信号 、 提 议 - 应 答 工 作 流 、 通 过 SDP 协商 会 话 参 


数 ， 也 深入 探讨 了 ICE 协议 在 建立 端 到 端 连接 时 的 内 部 工作 过 程 。 最 后 ， 我 们 知道 
了 通过 WebRTC 初始 化 端 到 端 连接 的 所 有 必要 细节 。 


1. 初始 化 WebRTC 连 接 
了 解 了 所 有 基本 知识 之 后 ， 下 面 我 们 就 来 看 一 个 初始 化 WebRTC 连接 的 完整 的 
例子 : 


<video id="local_video" autoplay></video> O@ 
<video id="remote video" autoplay></video> 四 


<script> 
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var ice = {"iceServers": [ 
{"url": "stun:stunserver.com:12345"}, 
{"url": "turn:user@turnserver.com", "credential": "pass"} 


]3; 


var signalingChannel = new SignalingChannel(); © 
var pc = new RTCPeerConnection(ice); @ 


navigator .getUserMedia({ "audio": true, "video": true }, gotStream, logError); © 


function gotStream(evt) { 
pc.addstream(evt.stream); GO 


var LocaL_video = document.getELementById('"LocaL_video ' ); 
LocalL_video.src = window.URL.createObjectURL(evt.stream); @ 


pc.createoffer(function(offer) { © 


pc.setLocalDescription(offer); 
signalingChannel.send(offer.sdp); 
]); 
} 


pc.onicecandidate = function(evt) { © 


if (evt.candidate) { 
signalingChannel.send(evt.candidate); 


} 
和 


signalingChannel.onmessage = function(msg) { @ 


if (msg.candidate) { 
pc.addIceCandidate(msg.candidate); 
} 
} 


pc.onaddstream = function (evt){@ 
var remote video = document.getElementById('remote video'); 
remote_video.src = window.URL.createObjectURL(evt.stream); 


} 


function LogError() { ... } 

</script> 
@ 输出 本 地 流 的 视频 元 素 
名 输出 远程 流 的 视频 元 素 
全 初始 共享 的 发 信 通 道 
@ 初始 端 连接 对 象 
@ 取得 本 地 音频 和 视频 流 
@ 通过 端 连 接 注册 本 地 MediaStream 
@@ 把 本 地 视频 流 输出 到 视频 元 素 (本 地 视图 ) 








@ 生成 描述 端 连接 的 SPD 提议 并 发 送 到 对 端 

















人 通过 发 信 通 道 向 对 端 增 量 发 送 ICE 候选 项 
@ 注册 远程 ICE 候选 项 以 开始 连接 检查 
@ 把 远程 视频 流 输出 到 视频 元 素 (远程 视图 ) 


看 第 一 遍 可 能 会 让 人 觉得 整个 过 程 有 点 难 理解 ， 不 要 灰心 。 既 然 我 们 已 经 理解 了 每 
一 步 的 工作 过 程 ， 整 个 过 程 也 不 如 此 : 初始 端 连接 和 发 信 通 道 ， 取 得 并 注册 媒体 流 ， 
发 送 提议 ， 递 增 提 交 ICE 候选 项 ， 最 后 再 输出 取得 的 媒体 流 。 如 果实 现 再 完整 一 
些 ， 还 应 该 注册 更 多 回调 函数 ， 以 跟踪 ICE 收集 和 连接 状态 ， 从 而 为 用 户 提供 更 多 


有 反馈 。 


5 





A 
‘0 4 
0, 





建立 连接 后 ， 应 用 仍然 可 以 通过 RTCPeerConnection 对 象 添 加 或 移 除 流 。 
每 次 添加 或 移 除 后 ， 都 会 自动 触发 新 的 一 次 SDP 协商 ， 重 复 一 遍 初始 化 
过 程 。 











2. 响应 WebRTC 连 接 
响应 新 WebRTC 连接 请 求 的 过 程 十 分 类 似 ， 主 要 区 别 是 在 发 信 通 道 交 付 SDP 提议 
之 后 才 会 开始 执行 大 部 分 逻辑 。 下 面 我 们 就 实际 地 看 一 看 : 





<video id="local_video" autoplay></video> 
<video id="remote video" autoplay></video> 


<script> 


var signalingChannel = new SignalingChannel(); 


var pc = null; 
var ice = {"iceServers": [ 


"url": "stun:stunserver.com:12345"}, 
{"url": "turn:user@turnserver.com", "credential": "pass"} 


]}; 


signalingChannel.onmessage = function(msg) { 
if (msg.offer) { © 
pc = new RTCPeerConnection(ice); 
pc.setRemoteDescription(msg.offer); 


navigator .getUserMedia({ "audio": true, "video": true }, 
gotStream, logError); 


} else if (msg.candidate) { 名 
pc.addIceCandidate(msg.candidate); 


} 
} 


function gotStream(evt) { 
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pc.addstream(evt .stream) ; 


var LocalL video = document.getElementById(' local video'); 
local_video.src = window.URL.createObjectURL(evt.stream); 


pc.createAnswer (function(answer) { © 


pc.setLocalDescription(answer); 
signalingChannel.send(answer .sdp); 
}); 
} 


pc.onicecandidate = function(evt) { 
if (evt.candidate) { 
signalingChannel.send(evt.candidate); 


} 
} 


pc.onaddstream = function (evt) { 
var remote video = document.getElementById('remote video'); 
remote_video.src = window.URL.createObjectURL(evt.stream); 


} 


function LogError() { ... } 
</script> 
@ 监听 并 处 理 通过 发 信 通 道 交付 的 远程 提议 
如 注册 远程 ICE 候选 项 以 开始 连接 检查 
@ 生成 描述 端 连 接 的 SDP 应 答 并 发 送 到 对 端 





毫 不 奇怪 ， 连 代码 看 起 来 都 十 分 相似 。 除 了 基于 由 共享 的 发 信 通 道 交 付 的 提议 消息 
初始 化 端 连接 的 工作 流 ， 唯 一 的 重要 区 别 就 在 于 前 面 的 代码 生成 的 是 一 个 SDP 应 
答 (通过 createAnswer) ， 而 非 提 议 对 象 。 除 此 之 外 ， 整 个 过 程 是 对 称 的 : 初始 化 
端 连接 ， 取 得 并 注册 媒体 流 ， 发 送 应 答 ， 增 量 提交 ICE 候选 项 ， 最 后 输出 取得 的 媒 
体 流 。 

既然 是 这 样 ， 我 们 只 要 复制 这 些 代 码 ， 再 加 上 发 信和 通道 的 实现 ， 就 有 了 一 个 在 浏览 
器 中 实时 的 、 端 到 端的 、 支 持 视频 和 音频 的 视频 会 议 应 用 。 想 一 想 ， 只 需 100 行 
JavaScript 代码 ， 不 错 啦 | 








通过 simpleWebRTC 初始 化 WebRTC 会 话 
实践 中 ， 前 面 的 代码 还 可 以 进一步 简化 。 我 们 这 个 例子 是 以 手工 方式 把 所 有 工作 
事 接 起 来 的 ， 但 实际 上 ， 没 有 理由 不 把 其 中 大 多 数 代 码 封 装 到 一 个 库 里 。 就 举 一 
个 使 用 simpleWebRTC 库 的 例子 吧 : 











294 | 第 18 章 


<script src="http://simplewebrtc.com/latest.js"></script> 


<div id="local_video"></div> 
<div id="remote_video"></div> 


<script> 
var webrtc = new WebRTC({ 
localVideoEl: "local_video", 
remoteVideosEl: "remote video", 
autoRequestMedia: true 


1); 


webrtc.on("readyToCall", function () { 
webrtc.joinRoom("your awesome room name"); 


3 


</sceript> 


以 上 这 几 行 JavaScript 代码 能 实现 与 前 面 例子 一 样 的 视频 会 议 功能 。 可 是 ， 这 里 也 
没有 什么 神秘 的 ， 只 不 过 simpleWebRTC 替 我 们 做 了 一 些 决定 而 已 。 在 这 几 行 代 
码 的 背后 ，simpleWebRTC 使 用 一 个 用 于 穿 透 NAT 的 公共 STUN 服务 器 初始 化 了 
RTCPeerConnection， 使 用 getUserMedia 请 求 音 a Ss 了 连接 到 它 
自己 发 信服 务 器 的 WebSocket 连接 。 而 应 用 要 做 的 ， 只 是 指定 一 个 “房间 名 ”， 那 
是 所 有 想 建 立 端 到 端 连 接 的 节点 都 必须 认可 的 。 

其 他 细节 请 大 家 参考 simpleWebRTC 的 文档 (http://simplewebrtc.com/) 。 值 得 一 提 
的 是 ， 这 个 项 目 还 提供 了 一 个 开源 的 发 信服 务 器 ， 你 可 以 利用 它 ， 也 可 以 在 实现 
自己 的 发 信服 务 器 时 参考 它 。 











18.5 ”交付 媒体 和 应 用 数据 


建立 端 到 端的 连接 需要 花 很 多 工夫 。 可 是 ， 即 便 两 端 完成 了 提议 -应答 工 作 流 ， 每 
端 也 完成 了 NAT 穿越 和 STUN 连接 检查 ， 在 WebRTC 协议 栈 中 仍然 只 走 了 一 半 的 
路 。 此 时 ， 两 端 相互 都 打开 了 原始 的 UDP 连接 ， 可 以 传输 基本 的 数据 报 ， 但 我 们 知 
道 仅仅 这 样 是 不 行 的 (参见 3.3 节 “ 针 对 UDP 的 优化 建议 ”) 。 


没有 流量 控制 、 拥 塞 控制 、 错 误 校 验 ， 以 及 一 些 预测 带宽 和 延迟 的 机 制 ， 很 容易 把 
网 络 搞 得 一 团 粳 ， 而 这 又 会 进一步 降低 两 端 及 周边 节点 的 性 能 。 另 外 ，UDP 以 明 
文 传输 数据 ， 而 WebRTC 要 求 对 所 有 通信 加 密 ! 为 解决 这 个 问题 ，WebRTC 又 在 
UDP 之 上 增加 了 几 层 协议 : 


。 数据 报 传输 层 安全 (DTLS ，Datagram Transport Layer Security) ， 用 于 加 密 传输 
应 用 数据 时 针对 要 传输 的 媒体 数据 协商 密 钥 ，; 
。 安全 实时 传输 (SRTP，Secure Real-Time Transport)， 用 于 传输 音频 和 视频 流 ; 
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。 流 控制 传输 协议 (SCTP，Stream Control Transport Protocol) 用 于 传输 应 用 数据 。 


18.5.1 通过 DTLS 实 现 安全 通信 

WebRTC 规范 要 求 所 有 传输 的 数据 (音频 、 视 频 和 自 定义 应 用 数据 ) 都 必须 加 密 。 
当然 啦 ， 如 果 不 是 因为 有 赖 于 TCP 的 有 序 交 付 ，TLS 是 最 合适 的 。 既 然 是 UDP 连 
接 ， 所 以 WebRTC 就 使 用 DTLS， 它 能 提供 与 TLS 相同 的 安全 保护 。 


DTLS 在 设计 上 有 意 与 TLS 保持 一 致 ， 事 实 上 ，DTLS 本 质 上 就 是 TLS， 只 是 为 了 
兼容 UDP 的 数据 报 传输 而 做 了 一 些微 小 的 修改 。 特 别 地 ，DTLS 解决 了 下 列 问题 : 


(1) TLS 要 求 可 靠 的 有 序 的 适合 分 段 的 握手 记录 以 协商 信道 ; 
(2) 如 果 在 混合 多 个 分 组 的 基础 上 对 记录 分 段 ， 就 不 能 保证 TLS 的 完整 性 校 验 ， 
(3) 如 果 记 录 的 顺序 不 对 ， 也 不 能 保证 TLS 的 完整 性 校 验 。 











增 
SR 要 了 解 担 手 过 程 和 记录 协议 结构 的 详细 信息 ， 请 参考 4.2 节 “TLS 担 手 ” 
4 ， 和 4.6 节 “TLS 记录 协议 ”。 

4 





坊 
1 


要 解决 TLS 握手 顺序 的 问题 并 不 简单 : 每 条 记录 都 有 特定 用 途 ， 而 且 必 须 按照 握手 
算法 规定 的 次 序 发 送 ， 而 有 些 记 录 轻 易 就 会 包含 多 个 分 组 。 结 果 ，DTLS 就 针对 担 
手 顺 序 实现 了 一 个 “迷你 TCP”( 图 18-11)。 





bP User Datagram Protocol, Src Port: 54153 (54153), Dst Port: 64964 (64964) 
v Datagram Transport Layer Security 
立 DTLSv1.0 Record Layer: Handshake Protocol: Client Hello 
Content Type: Handshake (22) 
Version: DTLS 1.0 (Oxfeff) 
Epoch: DO 
Sequence Number: 1 
Length: 146 
立 Handshake Protocol: Client Hello 
Handshake Type: Client Hello (1) 
Length: 134 
Message Sequence: 0 
Fragment Offset: 0O 
Fragment Length: 134 
Version: DTLS 1.0 (Oxfeff) 


图 18-11: DTLS 握手 记录 中 的 序号 和 分 段 偏 移 字 段 


DTLS 对 TLS 记录 协议 的 扩展 ， 就 是 为 每 条 握手 记录 明确 添加 了 分 段 偏 移 字 段 和 序 
号 。 这 样 就 满足 了 有 序 交 付 的 条 件 ， 也 能 让 大 记录 可 以 被 分 段 成 多 个 分 组 并 在 另 一 
端 再 进行 组 装 。DTLS 握手 记录 严格 按照 TLS 协议 规定 的 顺序 传输 ， 顺 序 不 对 就 报 
错 。 最 后 ，DTLS 还 要 处 理 丢 包 问 题 : 两 端 都 使 用 计时 器 ， 如 果 预 定时 间 内 没有 收 
到 应 答 ， 就 重 传 握手 记录 。 














di 
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记录 序号 、 偏 移 值 和 重 传 计 时 器 让 DTLS 在 UDP 之 上 实现 了 握手 (图 18-12) 。 为 
保证 过 程 完整 ， 两 端 都 要 生成 自己 签名 的 证 书 ， 然 后 按照 常规 的 TLS 握手 协议 走 。 

















18-12: 通过 DTLS 实现 端 到 端的 握手 


二 忆 





站 完整 的 DTLS 担 和 手 需要 两 次 往返 ， 这 一 点 必须 牢记 。 换 句 话 说， 建立 端 到 
人 心 4 ， 端 的 连接 会 产生 额外 延迟 。 

有 
WebRTC 客户 端 自动 为 每 一 端 生成 自己 签名 的 证 书 。 因 此 ， 也 就 没有 证 书 链 需 要 验 
证 。DTLS 保证 了 加 密 和 完整 性 ， 但 把 身份 验证 工作 留 给 了 应 用 ;参见 4.1 节 “ 加 
密 、 身 份 验证 与 完整 性 ”。 最 后 ， 在 满足 握手 要 求 的 基础 上 ，DTLS 为 处 理 常规 记录 
可 能 出 现 的 分 段 和 乱 序 问 题 ， 又 增加 了 两 条 重要 的 规则 : 


。 DTLS 记录 必须 刚好 放 到 一 个 网 络 分 组 中 ， 
。 必须 有 一 个 分 组 密码 用 于 加 密 记 录 数 据 。 


常规 TLS 记录 最 大 可 以 达到 16 KB。TCP 可 以 处 理 分 段 和 组 装 ， 但 UDP 不 提供 这 
些 服务 。 结 果 ， 为 适应 UDP 协议 的 乱 序 发 送 ， 也 为 了 最 大 程度 保持 其 语义 ， 每 个 携 
带 应 用 数据 的 DTLS 记录 都 必须 放 到 一 个 UDP 分 组 中 。 类 似 地 ， 由 于 它们 潜在 依赖 
记录 数据 的 有 序 发 送 ， 因 此 也 不 允许 使 用 流 密码 。 
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身份 与 验证 
WebRTC 两 冯 之 间 的 DTLS 握手 有 赖 于 自 签名 证 书 。 而 这 样 的 证 书 不 能 用 于 验证 
身份 ， 因 为 没有 要 验证 的 信任 链 (4.4 节 “ 信 任 链 与 证 书 颁发 机 构 ”)。 必 要 的 情况 
下 ，WebRTC 应 用 必须 自己 对 参与 各 端 进 行 认证 和 身份 验证 : 
。 Web 应 用 可 以 利用 之 前 用 于 建立 WebRTC 会 话 的 身份 验证 系统 (比如 通过 登 
录 来 验证 用 户 ) ; 
。 此 外 ， 每 一 广 也 可 以 在 生成 SDP 提议 /应答 时 指定 各 自 的 “身份 颁发 机 构 ”， 
等 对 端 接收 到 SDP 消息 后 ， 可 以 联系 指定 的 身份 颁发 机 构 验证 收 到 的 证 书 。 


后 一 种 “身份 颁发 机 构 ” 机 制 是 W3C WebRTC 工作 组 目前 还 在 讨论 和 制定 的 一 种 
机 制 。 要 了 解 最 新 进展 ， 可 以 阅读 相应 的 规范 和 邮件 列表 。 











18.5.2 通过 SRTP 和 SRTCP 交 付 媒体 


WebRTC 以 完全 托管 的 形式 提供 媒体 获取 和 交付 服务 : 从 摄像 头 到 网 络 ， 再 从 网 络 
到 屏幕 。WebRTC 应 用 指定 获取 流 的 媒体 约束 ， 然 后 通过 RTCPeerConnection 对 象 注 
册 它 们 (图 18-13)。 从 此 以 后 ， 就 都 是 浏览 器 提供 的 WebRTC 媒体 和 网 络 引 擎 的 事 
了 : 编码 优化 、 处 理 丢 包 、 网 络 拌 动 、 错 误 恢复 、 流 量 、 控 制 ， 等 等 。 












G) onaddstream 





基于 UDP 的 SRTP 











图 18-13: 通过 SRTP 和 SRTCP 交付 音频 和 视频 


这 种 架构 设计 的 用 意 很 简单 ， 就 是 应 用 除了 在 一 开始 指定 媒体 流 的 约束 外 (如 720p 
还 是 360p 视频 ) ， 无 法 直接 控制 媒体 如 何 优化 以 及 如 何 交付 给 另 一 端 。 这 样 的 设计 
是 有 意 为 之 的 ， 和 毕竟 ,通过 带宽 波动 、 分 组 延迟 的 不 可 靠 传输 机 制 交 付 高 品质 、 实 
时 的 音频 和 视频 ， 不 是 一 件 容易 的 事 。 浏 览 器 可 以 替 我 们 做 这 些 事 。 

。 不 用 关心 提供 的 媒体 流 的 品质 和 大 小 , 网 络 组 件 会 实现 自己 的 流 和 拥塞 控制 算法 ， 


让 每 个 连接 开始 时 的 比特 率 保持 较 低 (<500 Kbit/s)， 然 后 再 根据 带宽 调整 流 的 
品质 ， 
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。 在 连接 的 生命 周期 中 ， 浏 览 器 中 的 媒体 和 网 络 引擎 会 动态 调整 流 的 品质 ， 以 适 
应 不 断 变化 的 网 络 环境 ， 比 如 带宽 波动 、 丢 包 、 网 络 抖动 ， 等 等 。 换 名 话说 ， 
WebRTC 会 生成 自 适应 的 比特 流 (参见 6.4.2 节 中 的 “ 自 适 应 比特 流 ”)。 





WebRTC 不 能 保证 应 用 提供 的 高 清 视频 流 会 以 最 高 品质 交付 ， 因 为 端 到 端 之 间 的 带宽 
可 能 不 够 用 ， 而 且 丢 包 现象 很 常见 。 换 句 话 说， 引擎 会 适应 网 络 条 件 交 付 提 供 的 流 。 
芭 
虽然 实际 交付 的 音频 或 视频 流 的 品质 可 能 比 应 用 最 初 取得 的 流 的 品质 低 ， 
4 4 、 但 反 过 来 则 不 会 ，WebRTC 不 会 提升 流 的 品质 。 如 果 应 用 设置 了 360p 的 
必 ， 视 频 约束 ， 那 么 也 就 设 定 了 交付 视频 时 占用 带宽 的 上 限 。 














WebRTC 是 怎么 优化 和 调整 媒体 流 的 品质 的 呢 ? WebRTC 实际 上 并 不 是 通过 IP 网 
络 实时 交付 音频 和 视频 的 第 一 个 应 用 。WebRTC 只 是 重用 了 VoIP 电话 使 用 的 传输 
协议 、 通 信 网 关 和 各 种 商业 或 开源 的 通信 服务 : 














。 安全 实时 传输 协议 (SRTP，Secure Real-time Transport Protocol) 
通过 IP 网 络 交 付 音 频 和 视频 等 实时 数据 的 标准 安全 格式 。 








全 实时 控制 传输 协议 (SRTCP，Secure Real-time Control Transport Protocol) 
过 SRTP 流 交 付 发 送 和 接收 方 统 计 及 控制 信息 的 安全 控制 协议 。 




















。 然 而 ，WebRTC 要 求 传输 中 的 所 有 数据 都 必须 加 密 。 因 此 ，WebRTC 使 用 
的 是 RTP 的 “安全 版 ”(RFC 3711)。SRTP 和 SRTCP 前 面 那个 S， 就 是 
Secure (安全 )。 





Kg 实时 传输 协议 (RTP，Real-Time Transport Protocol) 由 RFC 3550 定义 。 
As 
4 





SRTP 为 通过 IP 网 络 交付 音频 和 视频 定义 了 标准 的 分 组 格式 〈 图 18-14)。SRTP 本 
身 并 不 对 传输 数据 的 及 时 性 、 可 靠 性 或 数据 恢复 提供 任何 保证 机 制 ， 它 只 负责 把 数 
字 化 的 音频 采样 和 视频 帧 用 一 些 元 数据 封装 起 来 ， 以 辅助 接收 方 处 理 这 些 流 。 


+8..15 +16..23 +24..31 














净 闪 类 型 
时 间 惟 
同步 源 (SSRC，Synchronization source) 标识 符 





参与 源 (CSRC，Contributing source) 标识 符 (可 选 ) 
RIP 扩 展 〈 可 选 ) 
加 密 的 RTP 净 荷 


SRTP MKI (可 选 ) + 认证 标签 (可 选 ) 




















图 18-14: SRTP 首部 (12 字 节 + 净 荷 及 可 选 字 段 ) 
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。 每 个 SRTP 分 组 都 包含 一 个 自动 递增 的 序号 ， 以 便 接 收 端 检测 和 发 现 媒体 数据 是 
否 乱 序 ， 

。 每 个 SRTP 分 组 都 包含 一 个 时 间 蕉 ,表示 媒 体 净 和 荷 第 一 字 节 的 采样 时 间 ， 用 于 多 
个 媒体 流 (如 音频 和 视频 ) 的 同步 ， 

。 每 个 SRTP 分 组 都 包含 一 个 SSRC 标识 符 ， 这 是 个 别 媒体 流 中 每 个 分 组 的 唯一 
六 ID; 

。 每 个 SRTP 分 组 可 以 包含 其 他 可 选 的 元 数据 ， 

。 每 个 SRTP 分 组 都 包含 加 密 的 媒体 净 荷 ， 以 及 (可 选 的 ) 认证 标签 ， 后 者 用 于 验 
证 分 组 的 完整 性 。 


SRTP 分 组 中 包含 了 媒体 引擎 实时 回放 流 必 需 的 所 有 信息 。 而 控制 每 个 SRTP 分 组 
交付 则 是 SRTCP 协议 的 责任 ，SRTCP 针对 每 个 媒体 流 实现 了 独立 的 外 部 反馈 渠道 。 


SRTCP 会 跟踪 发 送 及 丢失 字 节 和 分 组 的 数量 ， 跟 踩 每 个 SRTP 分 组 的 序号 、 交 错 到 
达 抖 动 ， 以 及 其 他 SRTP 统计 信息 。 然 后 ， 两 端 定时 交换 这 些 数 据 ， 以 便 调整 每 个 
流 的 发 送 速 率 、 编 码 品质 和 其 他 参数 。 


简单 地 说 ，SRTP 和 SRTCP 直接 在 UDP 之 上 运行 ， 共 同 完 成 对 应 用 提供 的 音频 和 
视频 流 的 实时 适 配 和 优化 。WebRTC 应 用 不 会 接触 内 部 的 SRTP 或 SRTCP 协议 : 
如 果 你 要 构建 自 定 义 的 WebRTC 客户 端 ， 那 得 直接 操作 这 两 个 协议 ， 否 则 浏览 器 会 
禁 你 搭建 好 所 有 必要 的 基础 设施 。 





¥ 


真 想 看 看 WebRTC 会 话 的 SRTCP 统计 信息 ? Chrome 就 可 以 让 你 看 到 延 
心 。 迟 、 比 特 率 和 带宽 等 情况 ， 详 情 请 见 18.4.5 节 中 的 “使 用 谷歌 Chrome 浏 
心 ， 览 器 检测 WebRTC 连接 状态 ”。 











适应 WebRTC 的 SRTP 和 SRTCP 


我 们 对 SRTP 和 SRTCP 的 介绍 简单 但 重点 突出 ， 不 过 对 实现 来 说 ， 为 了 让 这 两 个 
协议 达到 WebRTC 的 要 求 ， 还 需要 考虑 另外 一 些 细 节 。 


。 SRTP 和 SRTCP 都 会 加 密 应 用 净 荷 数据 (WebRTC 的 要 求 ) ， 但 它们 都 没有 
提供 协商 密 钥 的 机 制 ! 这 就 是 为 什么 必须 先进 行 DTLS 握手 的 原因 : DTLS 
握手 会 为 两 端 确定 一 个 共享 密 钥 ,随后 的 SRTP 和 SRTCP 可 以 使 用 这 个 密 钥 。 

。 SRTP 和 SRTCP 都 要 求 对 不 同 的 流 分 配 不 同 的 痛 口 ， 而 这 对 于 NAT 或 防火 
墙 后 面 的 客户 痛 当 然 就 是 一 个 问题 。 为 解决 这 个 问题 ，WebRTC 使 用 了 另 一 
个 多 路 复 用 扩展 ,以便 向 同一 个 目标 痛 口 交付 多 个 流 (以 及 相应 的 控制 信道 )。 

。 IETF 还 制定 了 一 个 新 的 拥塞 控制 算法 ， 该 算法 利用 SRTCP 的 反馈 对 
WebRTC 应 用 生成 的 音频 和 视频 流 进行 优化 。 
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总 之 ， 并 不 是 仅仅 把 数字 化 的 音频 和 视频 数据 转换 成 UDP 分 组 那么 简单 。 所 幸 
的 是 ，WebRTC 的 媒体 和 网 络 引 掌 替 我 们 承担 了 所 有 复杂 的 工作 。 而 适 配 和 改进 
SRTP 和 SRTCP 性 能 仍然 是 一 个 有 待 研究 的 领域 ， 包 括 标准 和 实现 层面 。 





18.5.3 通过 SCTP 交 付 应 用 数据 

除了 传输 音频 和 视频 数据 ，WebRTC 还 支持 通过 DataChannel API 在 端 到 端 之 间 传 
输 任意 应 用 数据 。 上 一 节 介 绍 的 SRTP 协议 是 专门 为 传输 媒体 数据 而 设计 的 ， 不 适 
合 传输 应 用 数据 。 因 此 ，DataChannel 就 依赖 于 SCTP (Stream Control Transmission 
Protocol， 流 控制 传输 协议 )， 而 SCTP 在 两 端 之 间 建 立 的 DTLS 信道 之 上 运行 
(图 18-3)。 








sx 


| 急 ， 在 探讨 SCTP 协议 之 前 ， 我 们 先 了 解 一 下 WebRTC 对 RTCDataChannel 接口 
及 其 传输 协议 有 哪些 要 求 。 


。 传输 层 必须 支持 多 个 独立 信道 的 复 用 : 
4 每 个 信道 必须 支持 有 序 或 乱 序 交付 ， 
4 每 个 信道 必须 支持 可 靠 或 不 可 靠 交 付 ， 
* 每 个 信道 可 以 支持 应 用 定义 的 优先 级 。 
。 传输 层 必须 提供 一 个 面向 消息 的 API: 
* 每 条 应 用 消息 都 可 能 在 传输 层 被 分 段 和 组 装 。 
。 传输 层 必须 实现 流量 和 拥塞 控制 机 制 。 
。 传输 层 必须 保证 数据 的 机 密 性 和 完整 性 。 











好 消息 是 ，DTLS 可 以 满足 最 后 一 条 要 求 : 所 有 应 用 数据 在 记录 的 净 荷 中 都 会 得 到 
加 密 ， 因 此 机 密 性 和 完整 性 就 落实 了 。 不 过 ， 其 他 要 求 可 没 那 么 容易 满足 。UDP 提 
供 的 是 不 可 靠 、 乱 序 的 数据 报 交 付 ， 而 除 此 之 外 我 们 还 需要 TCP 似 的 可 靠 交 付 、 信 
道 复 用 、 优 先 级 支持 、 消 息 分 段 ， 等 等 。 这 才 有 了 SCTP。 








表 18-1: TCP、UDP 与 SCTP 比 较 








TCR UDP SETRP 
可 靠 性 可 靠 不 可 靠 可 配置 
交付 次 序 有 序 乱 序 可 配置 
传输 方式 面向 字 市 面向 消息 面向 消息 
流量 控制 支持 不 支持 支持 
拥塞 控制 支持 不 支持 支持 
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SCTP 是 一 个 传输 层 协议 ， 直 接 在 IP 协议 上 运行 ,这 一 点 跟 TCP 和 UDP 
心 。 类 似 。 不 过 在 WebRTC 这 里 ，SCTP 是 在 一 个 安全 的 DTLS 信道 中 运行 ， 
”而 这 个 信道 又 运行 在 UDP 之 上 。 




















SCTP 同时 具备 TCP 和 UDP 中 最 好 的 功能 : 面向 消息 的 API、 可 配置 的 可 靠 性 及 交 
付 语义 ， 而且 内 置 流 量 和 拥塞 控制 机 制 。 我 们 不 打算 全 面 剖 析 SCTP 协议 ， 但 可 以 
简单 了 解 一 下 它 的 某 些 概念 和 术语 。 





关联 (association ) 

连接 的 同义词 。 

流 (stream) 

单 向 消息 传输 信道 ， 应 用 消息 在 其 中 有 序 交 付 ; 通过 配置 这 个 信道 ， 可 以 实现 乱 
序 交 付 。 





消息 (message) 


提交 给 这 个 协议 的 应 用 数据 。 


块 (chunk) 
SCTP 分 组 中 的 最 小 通信 单位 。 


两 个 端点 之 间 的 一 个 SCTP 关联 可 以 容纳 多 个 独立 的 流 ， 每 个 流 都 可 以 独立 传输 应 
用 消息 。 而 每 个 应 用 消息 又 可 以 被 分 割 成 一 或 多 个 块 ， 这 些 块 被 封装 在 SCTP 分 组 


( 


图 18-15) 中 交付 ， 等 到 了 另 一 端 再 组 装 起 来 。 











+0..7 


验证 标签 








| 


传输 序号 (TSN) 


流标 识 符 
净 荷 协议 标识 符 














18-15: SCTP 首部 和 数据 块 


这 
2.0 


些 概念 和 解释 听 起 来 是 不 是 很 熟悉 ”必须 的 呀 ! 名 词 不 同 ， 但 核心 概念 与 HTTP 
分 帧 层 中 那些 概念 是 一 样 的 ， 参见 12.3.2 节 “ 流 、 消 息 和 帧 *。 这 里 的 不 同 在 
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于 ，SCTP 是 在 “ 较 低层 ”实现 同样 的 功能 ， 从 而 可 以 支持 任意 应 用 数据 的 有 效 传 
输 及 多 路 复 用 。 


SCTP 分 组 由 公共 首部 及 一 或 多 个 控制 字段 或 数据 块 组 成 。 首 部 12 字 节 ， 用 于 标识 
来 源 和 目标 端口 、 针 对 当前 SCTP 关联 随机 生成 的 验证 标签 ， 以 及 整个 分 组 的 校 验 
和 。 首 部 后 面 是 一 或 多 个 控制 字段 或 数据 块 ， 图 18-15 中 所 示 的 数据 报 只 包含 一 个 
数据 块 。 





所 有 数据 块 的 类 型 都 是 0x0。 

U (unordered) 位 表示 数据 块 是 不 是 乱 序数 据 块 。 

B 生 位 用 于 表示 分 成 多 个 数据 块 的 消息 的 起 止 位 置 B=1，E=0 表示 消息 的 开 
始 位 置 ，B=0，E=0 表示 中 间 位 置 ， B=0，E=1 表示 末尾 位 置 ，B=1，E=1 表示 没 
有 分 段 的 消息 。 

长 度 表 示 数 据 块 的 大 小 ,包括 首部 (比如 ,16 字 节 的 块 首部 ,加 上 净 荷 数据 的 大 小 )。 
TSN (传输 序号 ) 是 一 个 32 位 数 ，SCTP 内 部 使 用 它 确 认 收 到 分 组 及 检测 重复 的 
分 组 。 

流标 识 符 表示 当前 数据 块 所属 的 流 。 

流 序号 是 一 个 自动 递增 的 消息 编号 ， 表 示 关 联 的 流 ; 分 段 消 息 的 流 序号 相同 。 
PPID ( 净 荷 协议 标识 符 ) 是 一 个 自 定义 字段 ， 由 应 用 填写 ， 用 于 沟通 与 传输 的 块 
相关 的 其 他 元 数据 。 








5 


DataChannel 使 用 SCTP 首部 的 PPID 字段 标记 传输 的 数据 类 型 : 0 x 51 表 
人 ， 示 UTF-8，0 x 52 表示 二 进 制 应 用 净 荷 。 


, 
(0, 





























一 下 子 说 了 这 么 多 ， 可 能 不 太 好 记 。 再 重复 一 遍 ， 这 次 我 们 在 前 面 提 到 的 WebRTC 
和 DataChannel API 要 求 的 背景 下 讨论 。 


SCTP 首部 包含 一 些 元 余 字 段 : SCTP 信道 建立 在 UDP 之 上 ， 后 者 已 经 指定 了 来 
源 和 目标 端口 (参见 图 3-2 ) 。 

SCTP 利用 首部 中 的 B、E 和 TSN 字段 辅助 处 理 消息 分 段 : 可 以 标识 每 个 块 的 位 
置 (开始 、 中 间 、 末 尾 )，TSN 值 用 于 表示 中 间 块 的 次 序 。 

SCTP 支持 流 的 多 路 复 用 : 每 个 流 都 有 一 个 唯一 的 流标 识 符 ， 用 于 关联 当前 数据 
块 与 活动 的 那个 流 。 

SCTP 为 每 条 应 用 消息 指定 一 个 独特 的 序号 ， 利 用 该 序号 可 以 实现 有 序 交付 的 语 
义 。 可 选 地 ， 如 果 设 置 了 UD 位 ( 乱 序 交 付 )，SCTP 可 以 继续 使 用 这 个 序号 来 处 
理 消息 分 段 ， 但 消息 可 以 乱 序 交付 。 
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地 


总 之 ，SCTP 会 给 每 个 数据 块 增加 28 字 节 开销 : 12 字 节 的 公共 首部 和 16 
心 4 ， 字 节 的 数据 块 首部 ， 然 后 才 是 应 用 净 荷 。 
DSN 

SCTP 怎么 协商 关联 的 初始 参数 呢 ? 每 个 SCTP 连接 都 需要 经 历 与 TCP 类 似 的 握手 
过 程 ! 类 似 地 ，SCTP 也 实现 了 TCP 友好 的 流量 和 拥塞 控制 机 制 : 两 个 协议 使 用 相 
同 的 初始 拥塞 窗口 大 小 ， 实 现 了 与 拥塞 预防 阶段 类 似 的 增 减 拥塞 窗口 的 逻辑 。 

幸 全， 

ng 要 回顾 一 下 TCP 握手 延迟 、 慢 启动 和 流量 控制 ， 请 参考 第 2 章 。WebRTC 
4 4 、 中 使 用 的 SCTP 操 手 以 及 拥塞 和 流量 控制 算法 不 一 样 ， 但 目的 相同 ， 而 且 

全， 在 性 能 方面 的 开销 也 类 似 。 























到 现在 为 止 ， 差 不 多 已 经 能 够 满足 WebRTC 的 所 有 要 求 了 。 然 而 可 惜 的 是 ， 就 算 有 
了 这 么 多 功能 ， 还 是 欠缺 几 个 关键 的 特性 。 


(1) 基础 的 SCTP 标准 (RFC 4960) 提供 了 乱 序 交付 消息 的 机 制 ， 但 不 支持 通过 配 
置 实现 可 靠 性 。 为 解决 这 个 问题 ，WebRTC 客户 端 必 须 另 外 求助 “Partial Reliability 
Extension”(RFC 3758) ， 也 就 是 对 SCTP 的 扩展 ， 为 的 是 支持 发 信 端 实现 自 定义 的 
交付 保证 ， 而 这 个 可 靠 性 是 DataChannel 的 关键 特性 。 

(2) SCTP 不 支持 对 流 的 优先 级 安排 协议 没有 规定 用 于 保存 优先 级 的 字段 。 因 此 ， 
这 个 功能 必须 由 更 高 层 协议 来 实现 。 








简 言 之 ，SCTP 与 TCP 提供 类 似 服务 ， 因 为 它 运行 于 UDP 之 上 ,而 且 由 WebRTC 
客户 端 实现 ， 所 以 它 的 API 必须 更 强大 : 有 序 和 乱 序 交 付 、 部 分 可 靠 性 、 面 向 消息 
的 API， 等 等 。 同 时 ，SCTP 也 有 握手 延迟 、 慢 启动 以 及 流量 和 拥塞 控制 ， 这 些 都 
是 在 考量 DataChanneL API 性 能 时 不 能 忽略 的 关键 因素 。 








“ 裸 SCTP” 的 挑战 
使 用 面向 消息 的 API 让 SCTP 避免 了 TCP 这 种 面向 流 的 协议 无 法 避免 的 队 首 阻塞 
问题 (参见 2.4 节 “ 队 首 阻塞 *)。 类 似 地 ， 同 样 的 机 制 也 让 SCTP 得 以 按 配置 交 
付 : 有 序 和 乱 序 、 可 靠 和 部 分 可 靠 。 


既然 如 此 ， 为 什么 不 直接 在 耳 协议 上 运行 SCTP， 然 后 通过 它 实现 所 有 数据 交换 
呢 ? 这 样 做 就 不 需要 UDP 了 ， 而 且 也 能 解决 将 来 通过 TCP 交付 HTTP 2.0 的 问题 
(参见 12.3.5 节 中 的 “ 丢 包 、 高 RTT 连 接 和 HTTP 2.0 性 能 ")。 事 实 上 ，SCTP 可 
以 解决 HTTP 2.0 解决 的 大 多 数 问 题 ， 也 能 让 我 们 大 幅度 简化 HTTP 协议 1 

只 可 惜 现 有 的 路 由 器 和 NAT 设备 不 能 正确 处 理 SCTP， 因 而 几乎 不 可 能 在 公共 互 
联网 上 将 SCTP 用 作 “ 裸 传输 协议 ”。WebRTC 这 才 在 UDP 和 DTLS 之 上 架设 起 
SCTP， 而 且 在 WebRTC 客户 端 中 ，SCTP 是 在 “用 户 空间 ”中 实现 的 。 
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在 内 部 网 等 受 控 的 环境 下 ，SCTP 的 性 能 很 好 。 很 多 移动 运营 商 部 使 用 SCTP 传输 
来 自 无 线 电 发 射 塔 的 数据 ， 直 到 穿 过 其 核心 网 络 传输 到 公共 互联 网 。 要 了 解 这 方面 
的 更 多 信息 ， 请 参考 这 个 链接 : http://tools.ietf.org/html/draft-ietf-behave-sctpnat。 





18.6 DataChannel 

DataChannel 支持 端 到 端的 任意 应 用 数据 交换 ， 就 像 websocket 一 样 ， 但 是 端 到 端 
的 ， 而 且 可 以 定义 底层 传输 协议 的 交付 属性 。 建 立 RTCPeerConnection 连接 之 后 ， 
两 端 可 以 打开 一 或 多 个 信道 交换 文本 或 二 进 制 数据 : 








function handleChannel(chan) { 0 


chan.onerror = function(error) { ... } 
chan.onclose = function() { ... } 


chan.onopen = function(evt) { 
chan.send("DataChannel connection established. Hello peer!") 


} 


chan.onmessage = function(msg) { 
if(msg.data instanceof Blob) { 
processBlob(msg.data); 
} else { 
processText(msg.data); 
} 
} 
} 


var signalingChannel = new SignalingChannel(); 
var pc = new RTCPeerConnection(iceConfig); 


var dc = pc.createDataChannel("namedChannel", {reliable: false}); © 


.© 


handleChannel(dc); @ 
pc.onDataChannel = handleChannel; © 


@ 在 DataChannel 对 象 上 注册 类 似 Websocket 的 回调 
@ 以 最 合适 的 交付 语义 初始 化 新 的 Datachannel 

@ 常规 的 RTCPeerConnection 提议 / 应 答 代 三 

@ 在 本 地 初始 化 的 Datachannel 上 注册 回调 

@ 在 远 端 初始 化 的 DataChanneL 上 注册 回调 


DataChannel API 有 意 照 搬 Websocket: 每 个 信道 都 会 触发 同样 的 onerror、onclose、onopen 





WebRTC | 305 


和 onmessage 回调 ， 而 且 每 个 信道 也 会 提供 同样 的 binaryType、bufferedAmount 和 
protocol 字段 。 

不 过 ， 由 于 DataChannel 是 端 到 端的 ， 而 且 在 更 灵活 的 传输 协议 之 上 运行 ， 因 此 它 还 
具备 一 些 Websocket 没有 的 功能 。 前 面 代码 示例 就 展示 了 这 其 中 一 些 最 重要 的 差别 : 











。 与 WebsSocket 构造 函数 不 同 它 需 要 传 入 Websocket 服务 器 的 URL， 而 
DataChannel 只 是 RTCPeerConnection 对 象 的 一 个 工厂 方法 ; 

。 与 WebSocket 不 同 ， 任 何 一 端 都 可 以 初始 新 的 DataCchannel 会 话 ， 会 话 建立 后 就 会 
触发 onDataChannel 回调 ， 

。 与 Websocket 不 同 ， 它 运行 在 可 靠 有 序 的 TCP 协议 之 上 ， 而 每 个 DataChannel 都 
可 以 经 过 配置 ， 实 现 自 定义 的 交付 和 可 靠 性 。 











DataChannel 与 WebSocket API 的 对 比 〈 表 18-2) 


DataChannel API 是 WebSocket API 的 超 集 ， 因 此 我 们 前 面 讨 论 过 的 关于 WebSocket 
的 一 切 ， 和 包括 回调 、 标 志 、 对 处 理 文 本 和 二 进 制 数 据 的 优化 ， 以 及 子 协 议 协商 ， 
都 可 以 直接 对 应 到 DataChanneL API; 参见 17.1 节 “WebSocket APT 。 


表 18-2: WebSocket 与 DataChannel 

















WebSocket DataChannel 

加 密 可 配置 始终 加 密 

可 靠 性 可 靠 可 配置 

交付 方式 有 序 可 配置 

多 路 复 用 不 支持 (有 扩展 ) 支持 

传输 机 制 面向 消息 面向 消息 

二 进 制 传输 支持 支持 

UTF-8 传输 支持 支持 

压缩 不 支持 (有 扩展 ) 不 支持 








当 然 啦 ，WebSocket 与 DataChanneL 最 大 的 区 别 ， 还 是 底层 传输 协议 不 一 样 。 
WebSocket 运行 在 TCP 之 上 ， 每 条 消息 的 交付 都 是 可 靠 且 有 序 的 ; 而 DataChannel 
运行 在 下 列 三 个 协议 之 上 : 

。 UDP 提供 痛 到 闹 的 连接 ; 

。 DTLS 对 传输 的 数据 加 窗 ; 

。 SCTP 支持 多 路 复 用 、 流 量 和 拥塞 控制 及 其 他 功能 。 

DataChannel 经 过 配置 ， 可 以 提供 与 WebSocket 相同 的 可 靠 性 和 有 序 交 付 语 义 。 当 
然 ， 更 重要 的 是 ，DataChannel 真正 的 威力 恰恰 在 于 它 不 一 定 必须 使 用 有 序 和 可 靠 
的 语义 | 每 个 信道 可 以 指定 自己 的 交付 和 可 靠 性 要 求 ， 而 数据 可 以 直接 从 一 端 传 
送 到 另 一 痛 。 
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18.6.1 设置 与 协商 

无 论 传输 的 是 什么 类 型 的 数据 (音频 、 视 频 ， 还 是 应 用 数据 ) ， 通 信 两 端 必须 首先 
经 过 完整 的 提议 /应答 流程 ， 协 商 要 使 用 的 协议 和 端口 ， 成 功 完成 连接 检查 (参见 
18.4 节 “ 建 立 端 到 端的 连接 ”) 。 


事实 上 ， 正 像 我 们 现在 已 经 知道 的 ， 传 输 媒 体 使 用 SRTP， 而 DataChannet 使 用 
SCTP 协议 。 因 此 ， 初 始 端 在 生成 连接 提议 ， 或 者 另 一 端 在 生成 应 答 时 ， 它 们 两 个 
必须 特意 在 生成 的 SDP 字符 串 中 包含 SCTP 关联 的 参数 : 


的 内 容 ……) 
m=application 1 DTLS/SCTP 5000 ©@ 


c=IN IP4 0.0.0.0 © 
a=mid:data 
a=fmtp:5000 protocol=webrtc-datachannel; streams=10 © 


( a 省 略 的 内 容 a ) 


@ 告知 对 方 想 使 用 DTLS 之 上 的 SCTP 
@ 0.0.0.0 候选 项 表示 使 用 增 量 ICE 
全 SCTP 之 上 的 DataChannel 协议 ， 最 多 10 个 并 行 流 

















一 、 
Wy 
中 

= 


























跟 以 前 一 样 ， 只 要 任意 一 端 在 生成 会 话 的 SDP 描 述 前 注册 DataChannel， 
RTCPeerConnection 就 会 负责 生成 SDP 参数 。 实 际 上 ， 应 用 通过 明确 设置 禁用 音频 
和 视频 传输 的 约束 ， 可 以 建立 只 传输 数据 的 端 到 端 连接 : 

















var signalingChannel = new SignalingChannel(); 
var pc = new RTCPeerConnection(iceConfig); 


var dc = pc.createDataChannel("namedChannel", {reliable: false}); © 


var mediaConstraints = { 名 
mandatory: { 
OfferToReceiveAudio: false, 
OfferToReceiveVideo: false 
上 
}; 


pc.createOffer(function(offer) { ... }, null, mediaConstraints); © 





@ 通过 RTCPeerConnection 注册 新 的 不 可 靠 的 DataChannel 
@ 设置 媒体 约束 ， 以 禁用 音频 和 视频 传输 
@ 生成 只 传输 数据 的 提议 
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协商 确定 了 SCTP 参数 后 ， 很 快 就 可 以 交换 应 用 数据 。 注 意 ， 前 面 看 到 的 SDP 片段 
中 并 未 提 到 每 个 DataCchannel 的 参数 ， 比 如 协议 、 可 靠 性 ， 或 者 有 序 或 乱 序 标签 。 
因此 ， 在 可 以 发 送 应 用 数据 之 前 ， 初 始 的 WebRTC 客户 端 还 要 发 送 DATA_CHANNEL_ 
OPEN 消息 (图 18-16)， 这 个 消息 描述 了 数据 类 型 、 可 靠 性 、 要 使 用 的 应 用 协议 ， 及 
信道 的 其 他 参数 。 











ne) | mann | 


可 靠 性 


[| 
EE EE 














18-16: DATA_CHANNEL_OPEN 消息 初始 化 新 信道 


DATA_CHANNEL_OPEN 消息 与 HTTP 2.0 中 的 HEADERS 帧 类 似 : 它 显 式 地 打开 一 
个 新 流 ， 随后 可 以 立即 发 送 数据 帧 ， 参见 12.4.1 节 “ 发 起 新 流 ”。 要 了 解 
， 有 关 DataChannel 协议 的 更 多 信息 ， 请 参考 这 个 链接 : http://tools.ietf.org/ 
ee ut 











沟通 完 信道 参数 ， 两 端 就 可 以 交换 应 用 数据 了 。 本 质 上 ， 每 个 信道 都 作为 一 个 独立 
的 SCTP 流 发 送 数据 ， 即 所 有 信道 都 是 在 同一 个 SCTP 关联 之 上 多 路 复 用 出 来 的 。 
这 样 就 可 以 避免 不 同 流 之 间 的 队 首 阻塞 ,在 同一 个 SCTP 关联 上 同时 打开 多 个 信道 。 























外 部 信道 协商 
DataChannel 也 允许 通过 外 部 协商 信道 参数 。 在 调用 createDataChannel 方法 时 ， 
应 用 可 以 把 negotiated 参数 设置 为 true， 这样 就 不 会 自动 发 送 DATA_CHANNEL_ 
OPEN 消息 。 不 过 ， 这 样 一 来 ， 两 篇 就 必须 指定 相同 的 id 参数 ， 这 个 参数 可 以 由 浏 
览 器 自 动 渤 左 ， 


signalingChannel.send({ © 

newchannel: true, 
label: "negotiated channel", 
options: { 

negotiated: true, 

id: 10， 

reliable: true, 

ordered: true, 

protocol: "appProtocol-v3" 
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} 
下》 


signalingChannel.onmessage = function(msg) { 
if (msg.newchannel) { 
dc = pc.createDataChannel(msg.label, msg.options); 
} 
} 


@ 通过 发 信和 通道 向 另 一 端 发 送信 道 配置 
@ 唯一 的 应 用 指定 的 信道 IJD (整数 ) 
@ 用 接收 到 的 参数 初始 化 新 DataChannel 


实践 中 ， 如 果 通 信 痛 的 数量 不 多 ， 使 用 外 部 协商 的 性 能 优势 并 不 明显 。 这 时 候 ， 
还 是 让 RTCPeerConnection 对 象 帮 我 们 完成 协商 更 好 。 然 而 ， 在 通信 端的 数量 很 
多 的 情况 下 ， 发 信服 务 器 可 以 生成 相同 的 描述 ， 同 时 将 它们 分 发 给 所 有 通信 端 。 
此 时 ， 这 种 工作 流 就 能 派 上 用 场 。 











18.6.2 配置 消息 次 序 和 可 靠 性 

DataChannel 可 以 让 我 们 使 用 兼容 websocket 的 API 端 到 端 地 传输 任意 数据 ， 就 其 本 
身 而 言 ， 这 绝对 是 独一无二 而 且 十 分 强大 的 功能 。 可 是 ，DataChannel 还 支持 一 种 
灵活 得 多 的 传输 方式 ， 因 此 我 们 可 以 自 定义 每 个 信道 的 交付 语义 ， 以 满足 应 用 和 要 
传输 的 数据 类 型 的 需要 : 


。 DataChannel 可 以 有 序 或 大 序 交付 消息 ， 
。 DataChannel 可 以 可 靠 或 部 分 可 靠 地 交付 消息 。 





当然 ， 要 把 信道 配置 成 有 序 且 可 靠 交 付 ， 那 就 与 TCP 无 异 了 : 与 常规 的 Websocket 
交付 效果 相同 。 然 而 ，DataChannel 还 为 每 个 信道 配置 部 分 可 靠 性 提供 了 两 个 选择 : 











。 通过 重 传 实现 部 分 可 靠 交 付 

消息 的 重 传 次 数 由 应 用 指定 。 
。 通过 超时 实现 部 分 可 靠 交 付 

消息 的 重 传 间隔 (ms) 由 应 用 指定 。 
这 两 个 选择 都 由 WebRTC 客户 端 实现 ， 意 味 着 应 用 所 要 做 的 ， 只 是 决定 使 用 什么 交 
付 模型 ， 然 后 对 信道 设置 正确 的 参数 即 可 。 应 用 不 管理 计时 器 或 重 传 计数 器 。 下 面 
我 们 再 介绍 一 下 配置 选项 ( 表 18-3)。 
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表 18-3: DataChannel 的 可 靠 性 和 交付 模型 配置 








有 序 可 靠 部 分 可 靠 策略 
有 序 + 可 靠 是 是 N/A 
乱 序 + 可靠 否 是 N/A 
有 序 + 部 分 可 靠 ( 重 传 ) 是 部 分 重 传 计数 
乱 序 + 部 分 可 靠 ( 重 传 ) 否 部 分 重 传 计数 
有 序 + 部 分 可 靠 (定时 ) 是 部 分 超时 (ms) 
乱 序 + 部 分 可 靠 (定时 ) 否 部 分 超时 (ms) 


有 序 且 可 靠 交 付 很 好 理解 ， 就 是 TCP。 另 一 方面 ， 乱 序 且 可 靠 交 付 很 有 意思 ， 它 也 
是 TCP,， 但 没有 队 首 阻塞 问题 (参见 2.4 市 “ 队 首 阻塞 ” )。 


配置 部 分 可 靠 的 信道 时 ， 关 键 是 要 记 住 两 个 重 传 策略 是 互 斥 的 。 换 名 话说 ， 应 用 可 
以 指定 超时 重 传 ， 也 可 以 指定 计数 重 传 ， 但 不 能 同时 指定 两 个 策略 ;否则 ， 就 会 报 
错 。 好 了 了， 下面 我 们 来 看 一 看 用 于 配置 信道 的 JavaScript API 吧 : 





conf = {}; © 

conf = { ordered: false }; © 

conf = { ordered: true, maxRetransmits: customNun }; © 
conf = { ordered: false, maxRetransmits: customNun }; @ 
conf = { ordered: true, maxRetransmitTime: customMs }; © 
conf = { ordered: false, maxRetransmitTime: customMs }; @ 


conf = { ordered: false, maxRetransmits: 0 }; 0 


var signalingChannel = new SignalingChannel(); 
var pc = new RTCPeerConnection(iceConfig); 


var dc = pc.createDataChannel("namedChannel", conf); ©@ 


if (dc.reliable) { 


jelse 
@ 默认 为 有 序 可 靠 交 付 (TCP) 
@ 可 靠 乱 序 交付 


全 有 序 、 部 分 可 靠 , 使 用 自 定义 的 重 传 计数 
@ 乱 序 、 部 分 可 靠 ， 使 用 自 定义 的 重 传 计数 
加 有 序 、 部 分 可 靠 ， 使 用 自 定义 的 超时 重 传 
@ 乱 序 、 部 分 可 靠 ， 使 用 自 定义 的 超时 重 传 
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@ 乱 序 不 可 靠 交 付 (UDP) 
@ 使 用 指定 的 配置 初始 化 DataChannel 


初始 化 DataChannel 之 后 ,应 用 可 以 访问 maxRetransmits 和 maxRetrans- 
人 4，mitTime 这 两 个 只 读 属性 。 同 样 ， 为 方便 起 见 ，DataChannet 也 提供 了 一 
二 个 reliable 属性 ， 只 要 使 用 了 部 分 可 靠 策略 ， 这 个 属性 就 会 返回 false。 








每 个 DataChannel 可 以 使 用 不 同 的 自 定义 参数 (可靠 性 及 是 否 有 序 ) 来 配置 ， 每 一 
端 可 以 打开 多 个 信道 ， 这 些 信道 都 是 通过 对 相同 的 SCTP 关联 多 路 复 用 实现 的 。 结 
果 ， 信道 之 间 相 互 独立 ， 可 以 分 别 用 于 传输 不 同类 型 的 数据 。 比 如 ， 可 靠 有 序 的 信 
道 可 用 于 聊天 ， 部 分 可 靠 且 乱 序 的 交付 可 用 于 传输 瞬时 或 低 优 先 级 的 应 用 更 新 。 


18.6.3 ”部 分 可 靠 交 付 与 消息 大 小 
要 使 用 部 分 可 靠 的 信道 ， 需 三 思 而 后 行 。 尤 其 是 ， 应 用 必须 密切 关注 消息 大 小 : 应 
用 传输 的 数据 可 能 很 大 ， 因 此 会 被 分 段 封装 到 多 个 分 组 中 ， 而 这 很 可 能 导致 难以 接 
受 的 结果 。 为 说 明 这 个 问题 ， 假 设 有 以 下 场景 














。 两 端 协 商 好 了 一 个 乱 序 不 可 靠 的 DataChannel。 
。 信道 的 maxRetransmits 为 0， 即 纯粹 是 UDP。 

。 丢 包 率 大 约 为 1%。 

。 其 中 一 端 想 要 发 送 一 个 120 KB 的 大 消息 。 


WebRTC 客户 端 将 SCTP 分 组 的 最 大 传输 单位 设置 为 1280 字 节 ， 这 是 针对 IPv6 分 
组 推荐 的 MTU。 但 我 们 也 必须 考虑 到 IP、UDP、DTLS 和 SCTP 协议 的 开销 ， 分 别 
是 20~40 字 节 、8 字 节 、20~40 字 节 和 28 字 节 ， 加 起 来 大 约 为 130 字 节 。 这 样 每 个 
分 组 就 剩 下 大 约 1150 字 节 给 数据 净 荷 。 因 此 ，120 KB 应 用 消息 总 共 需 要 107 个 分 
组 (120 x 1024/1150) 。 











现在 还 看 不 出 有 问题 ， 但 每 个 分 组 丢失 的 概率 为 1%。 如 果 我 们 通过 不 可 靠 信道 发 
送 全 部 107 个 分 组 ， 那 么 极 有 可 能 在 中 途 会 丢失 其 中 一 个 ! 这 会 导致 什么 结果 呢 ? 
即使 仅仅 丢失 一 个 分 组 ， 整 个 消息 也 会 被 抛弃 。 


为 解决 这 个 问题 ， 应 用 有 两 个 选择 : 可 以 使 用 重 传 策略 (计数 或 超时 )， 或 者 减少 消 

息 大 小 。 事 实 上 ， 为 了 获得 最 住 结 果 ， 应 该 双管齐下 。 

。 在 使 用 不 可 靠 信 道 时 ， 理 想 情 况 下 ， 每 个 消息 都 应 该 可 以 封装 到 一 个 分 组 中 。 换 
句 话说， 消息 应 该 小 于 1150 字 节 。 

。 如 果 消 息 不 能 封装 到 一 个 分 组 中 , 则 需要 使 用 重 传 策略 , 以 提高 交付 消息 的 成 功率 。 
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端 到 端 之 间 的 丢 包 和 延迟 难以 预测 ， 会 因 当 时 的 网 络 环境 而 变化 。 因 此 ， 对 于 重 传 
次 数 ， 或 者 超时 间隔 ， 并 没有 唯一 的 最 优 答案 。 为 了 通过 不 可 靠 信 道 达成 最 佳 结果 ， 
请 尽量 减少 消息 大 小 。 











18.7 WebRTC 使 用 场景 及 性 能 


实现 低 延 迟 、 端 到 端的 传输 可 不 是 件 轻而易举 的 事 ， 它 涉及 NAT 穿越 和 连接 检查 、 信 
号 发 送 、 安 全 加 密 、 拥 塞 控制 及 大 量 其 他 必须 考虑 到 的 细节 。WebRTC 为 我 们 处 理 了 
上 述 所 有 这 些 , 而 且 还 不 止 这 些 。 正 因为 如 此 ，WebRTC 自问 世 起 就 被 人 们 追捧 为 对 
Web 平台 有 史 以 来 最 重要 的 补充 。 关 键 在 于 ，WebRTC 不 仅 是 实现 了 这 些 功能 ， 而 且 
保证 了 所 有 组 件 协同 工作 ， 为 我 们 在 浏览 器 中 构建 端 到 端 应 用 提供 了 简单 统一 的 API。 


不 过 ， 即 便 有 了 内 置 的 服务 ， 设 计 高 效 高 性 能 的 端 到 端 应 用 仍然 需要 周密 考虑 和 规 
划 : 端 到 端 本 身 并 不 代表 高 性 能 。 如 果 说 有 什么 不 同 ， 那 就 是 端 到 端 之 间 的 带宽 和 
延迟 越 来 越 多 变 ， 对 媒体 传输 的 需求 日 益 增 长 ， 以 及 不 可 靠 交 付 的 诸多 特性 反倒 进 
一 步 增 加 了 这 种 应 用 的 构建 难度 。 








18.7.1 音频、 视频 和 数据 流 

端 到 端的 音频 和 视频 流 是 WebRTC 最 主要 的 使 用 场景 之 一 : getUserMedia API 可 以 
让 应 用 获取 媒体 流 ， 而 内 置 的 音频 和 视频 引 敬 负责 处 理 优化 、 错 误 恢复 和 流 之 间 的 
同步 。 不 过 不 要 忘 了 ， 即 便 经 过 十 分 激进 的 优化 和 压缩 ， 音 频 和 视频 交付 依旧 可 能 
受到 延迟 和 带宽 的 限制 .: 








。 高 清 的 流 至 少 需 要 1~2 Mbits 带宽 ,参见 18.2 节 中 的 “音频 (Opus) 与 视频 (VP8) 
比特 率 ”; 

。 截至 2013 年 第 一 季度 ， 全 球 平 均 带 宽 只 有 3.1 Mbit/s， 参 见 表 1-2， 

。 高 清 的 流 至 少 要 求 3.5G+ 的 连接 ， 参 见 表 7-2。 


好 消息 是 ， 世 界 平均 带宽 一 直 在 稳步 增长 : 用 户 正 在 向 宽带 转移 ， 而 3.5G+ 和 4G 
网 络 的 应 用 速度 也 在 加 快 。 可 是 ， 就 算 乐 观 估计 ， 也 只 能 说 高 清流 在 今天 是 可 行 的 ， 
还 不 能 说 有 保证 ! 类 似 地 ， 延 迟 是 一 个 老生 常 谈 的 问题 ， 特 别 是 对 实时 交付 以 及 移 
动 客户 端 ， 延 迟 的 问题 更 加 严重 。4G 当然 好 ， 但 3G 网 络 要 退出 历史 舞台 也 不 是 一 
朝 一 夕 的 事 。 

















uw 有， 的 下 行 吞吐 量 明显 高 于 上 行 吞 吐 量 。 事 实 上 ，10 : 1 的 比例 不 在 少数 ， 也 就 


二 二 

1 更 严重 的 是 ， 大 多 数 ISP 和 移动 运营 商 提供 的 连接 并 不 对 称 : 大 多 数 用 户 
4 

一 4 是 说 下 载 10 Mbit/s， 上 传 只 有 1 Mbit/s。 





312 | 第 18 章 


最 终结 果 就 是 ， 仅 仅 一 条 端 到 端的 音频 和 视频 流 ， 就 会 占用 大 部 分 的 用 户 带 宽 ， 而 
移动 客户 端 就 是 更 如 此 了 。 那 如 果 是 多 方 流 呢 ? 肯定 需要 对 可 用 带宽 有 一 个 明确 的 
把 握 : 


。 移动 客户 端 或 许可 以 下 载 高 清流 (1 Mbit/s 以 上 ), 但 图 于 上 行 吞 吐 量 ,或 许 只 能 
发 送 低 品质 流 ， 即 不 同 通 信 端 接收 和 发 送 流 的 比特 率 不 同 ，; 

。 音频 和 视频 流 可 能 需要 与 其 他 应 用 和 数据 传输 服务 共享 带宽 ， 比 如 多 个 
DataChannel 会 话 ; 

。 带宽 和 延迟 一 直 在 变 ， 与 连接 类 型 《有线 或 无 线 ) 或 者 第 几 代 网 络 无 关 ， 因 此 应 
用 必须 能 适应 这 些 变化 。 




















好 在 WebRTC 的 音频 和 视频 引擎 会 与 底层 的 网 络 传输 组 件 协同 ， 去 探测 可 用 带宽 ， 
从 而 优化 媒体 流 的 交付 。 可 是 ，DataChannel 还 需要 额外 的 应 用 逻辑 : 应 用 必须 监 
控 缓 冲 区 中 的 数据 量 ， 随 时 准备 按 需 作出 调整 。 





地 。， 


在 采集 音频 和 视频 流 时 ， 一 定 要 将 视频 约束 设置 为 与 使 用 场景 匹配 ， 参 见 
心 。18.2 节 中 的 “通过 getUserMedia 获取 音频 和 视频 ”。 


(0, 


18.7.2” 多方 通信 和 架构 

一 个 双向 发 送 高 清 媒 体 流 的 端 到 器 连接 ， 很 容易 耗 尽 用 户 的 带宽 。 为 此 ， 对 于 多 方 
通信 的 场景 ， 就 更 应 该 仔细 考虑 其 架构 了 (图 18-17) ， 特 别 是 单个 流 如 何 汇 聚 ， 以 
及 如 何在 端 与 端 之 间 分 发 。 


At 
本 I 人 


双向 呼 中 四 向 呼叫 四 向 呼叫 四 向 呼叫 
网 状 网 星 形 网 络 集中 分 发 



































图 18-17: W 向 呼叫 的 分 布 式 架构 
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一 对 一 连接 最 容易 处 理 和 部 署 : 两 端 直 连 即 可 ， 不 需要 进一步 优化 。 可 是 ， 如 果 对 
一 个 NN 方 呼叫 扩展 这 个 策略 ， 那 么 每 一 端 都 要 分 别 连 接 到 其 他 端 (网 状 网 络 )， 即 
每 一 端 有 N-17 个 连接 ， 总 共 是 Nx(N-7) 个 连接 ! 如 果 带 宽 有 限 ， 特 别 是 上 行 速度 更 
低 ， 那 么 这 种 架构 下 只 需 少 数 参与 端 就 会 消耗 掉 用 户 的 大 多 数 带 宽 。 

网 状 网 络 虽 然 容 易 建 立 ， 但 对 多 方 流 交换 而 言 往往 效率 很 低 。 为 解决 这 个 问题 ， 赫 代 
方案 是 使 用 “ 星 形 ” 拓 扑 ， 让 每 一 端 连接 到 一 个 “超级 节点 "， 由 它 负责 向 连接 各 方 
分 发 流 。 这 样 ， 只 有 一 个 节点 需要 处 理 和 分 发 N-7 个 流 ， 其 他 市 点 都 与 它 直接 对 话 。 

















超级 节点 可 以 是 普通 的 参与 端 ， 也 可 以 是 一 个 为 处 理 和 分 发 实时 数据 而 优化 过 的 专 
用 服务 器 。 至 于 哪个 策略 更 合适 ， 还 得 看 使 用 场景 和 应 用 。 最 简单 的 情况 下 ， 发 起 
连接 的 一 端 可 以 作为 超级 节点 一 一 简单 ， 但 效果 不 可 能 太 好 。 更 好 的 办 法 则 是 选择 
可 用 吞吐 量 最 大 的 通信 端 ， 但 这 样 又 需要 额外 的 “挑选 ”和 发 信 机 制 。 





挑选 条 件 和 过 程 由 应 用 决定 ， 而 这 本 身 又 是 一 个 难题 。WebRTC 没有 为 此 
人 4 、 提 供 任何 辅助 机 制 。 


Qi 








最 后 ， 超 级 节点 可 以 是 专用 的 ， 甚 至 还 可 以 是 第 三 方 服务 。WebRTC 能 让 我 们 实现 
端 到 端的 通信 ， 但 这 并 不 意味 着 不 能 考虑 集中 式 架构 | 如 果 每 一 端 都 与 代理 服务 器 建 
立 连接 ， 那 么 既 可 以 利用 WebRTC 提供 的 传输 机 制 ， 又 可 以 使 用 服务 器 提供 的 服务 。 





端 到 端 优化 即 服务 
很 多 现 有 的 视频 会 议 解决 方案 (比如 谷歌 的 Hangouts) 都 依赖 “代理 服务 器 ” 汇 
聚 个 别 的 媒体 流 ， 然 后 合成 ， 再 将 优化 的 版 本 分 发 给 连接 各 端 。 只 交付 一 个 流 可 
以 减少 对 每 一 端 带 宽 和 CPU、GPU 资源 的 占用 ， 因 为 每 一 端 只 看 到 一 个 流 ， 而 非 
N-7 个 | 


类 似 地 ， 一 台 游 戏 服务 器 可 以 汇聚 所 有 玩家 的 更 新 ， 通 过 筛选 ， 只 分 发 必要 的 更 
新 。 比 如 ， 不 给 处 在 视野 之 外 的 玩家 发 送 更 新 ， 也 不 会 影响 其 他 玩家 。 


两 端的 流 交 换 很 简单 ， 部 署 效率 高 ， 而 多 方 架构 则 要 求 考 虑 很 多 ， 周 密 规 划 。 
WebRTC 很 大 程度 上 是 为 闹 到 闯 直 接 通 信服 务 的 ， 因 此 也 催生 了 很 多 其 他 服务 ， 
有 商业 的 ， 也 有 开源 的 。 这 些 服务 反 过 来 又 会 提升 WebRTC 应 用 的 效率 ， 丰 富 其 
功能 。 











18.7.3 ”基础 设施 及 容量 规划 
除了 规划 和 预测 每 一 端的 带宽 需求 ，WebRTC 应 用 还 需要 基 些 集中 式 基 础 设施 来 发 
信 、 穿 越 NAT 和 防火 墙 、 身 份 验证 ， 以 及 其 他 服务 。 
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WebRTC 把 发 信 功 能 留 给 应 用 实现 ， 这 意味 着 应 用 最 低 限 度 也 要 实现 两 端的 消息 发 
送 和 接收 逻辑 。 发 信 数 据 量 因 用 户 数量 、 协 议 、 数 据 编码 和 更 新 频率 而 异 。 类 似 地 ， 
发 信服 务 的 延迟 对 “呼叫 建立 ”时 间 (尤其 是 使 用 增 量 ICE 的 时 候 ) 及 其 他 发 信 交 
换 性 能 影响 极 大 。 


。 使 用 低 延 迟 的 传输 方案 ， 比 如 WebSocket 或 基于 XHR 的 SSE。 

。 估计 并 提供 足够 的 容量 ， 以 满足 所 有 应 用 必需 的 信号 发 送 速 率 。 

。 可 选 地 ， 建 立 连 接 后 ， 各 端 可 以 切换 到 Datachannel 来 发 信 。 这 样 可 以 转移 中 心 
服务 器 必须 处 理 的 发 信 流 量 ， 也 会 减少 发 信 过 程 的 延迟 。 

由 于 NAT 和 防火 墙 的 广泛 存在 ， 大 多 数 WebRTC 应 用 都 将 需要 STUN 服务 器 来 执 

行 IP 查找 ， 从 而 建立 端 到 端 连接 。 好 在 ， 只 有 连接 设置 阶段 才 需 要 STUN 服务 器 ， 

但 无 论 如 何 ， 它 都 必须 采用 STUN 协议 且 随 时 可 用 ， 以 处 理 必要 的 查询 。 





。 除非 WebRTC 应 用 只 在 同一 内 部 网 络 中 使 用 , 否则 始终 都 要 在 RTCPeerConnection 
对 象 中 提供 STUN 服务 器 ;不然 ， 大 多 数 连接 会 直接 失败 。 

。 与 发 信服 务 器 可 以 使 用 任何 协议 不 同 ，STUN 服务 器 必须 响应 STUN 请 求 。 可 以 
选择 一 台 公 共 服 务 器 ， 也 可 以 自己 配置 ，stund 就 是 一 个 流行 的 开源 实现 。 


即便 有 了 STUN，8%~10% 的 端 到 端 连 接 也 可 能 由 于 网 络 策略 存在 的 各 种 问题 而 失 
败 。 比 如 ， 网 络 管理 员 可 能 会 屏蔽 网 络 中 所 有 用 户 的 UDP 数据 报 (参见 3.2.3 节 中 
的 “现实 中 的 STUN 和 TURN”)。 为 此 ， 要 保证 用 户 体验 ， 应 用 可 能 还 需要 一 台 
TURN 服务 器 在 端 与 端 之 间 转 发 数据 。 


。 转发 数据 是 一 种 次 优选 择 : 转发 就 会 导致 多 余 的 网 络 跳跃 ， 而 在 每 个 流 占 用 1 
Mbit/s 带宽 的 情况 下 ， 任 何 服务 都 可 能 很 快 被 耗 尽 带宽 。 所 以 ，TURN 应 该 是 没 
有 办 法 的 办 法 ， 实 在 不 行 才 用 ， 而 且 即 便 用 ， 也 要 仔细 对 待 容量 规划 问题 。 


多 方 服务 可 能 需要 集中 式 基础 设施 来 辅助 优化 多 个 流 的 交付 ， 从 而 成 为 RTC 体验 的 
一 部 分 。 很 多 时 候 ， 多 方 网 关 会 扮演 与 TURN 相同 的 角色 ， 但 这 里 的 需求 不 同 。 话 
虽 如 此 ， 但 与 TURN 服务 器 充当 简单 的 分 组 代理 不 同 ， 这 些 “智能 代理 ”在 向 各 端 
转发 最 终 输 出 前 ， 可 能 要 占用 更 多 CPU 和 GPU 资源 来 处 理 每 一 个 流 。 

















18.7.4 数据 效率 及 压缩 
WebRTC 音频 和 视频 引擎 会 根据 端 与 端 之 间 的 网 络 条 件 动态 调整 媒体 流 的 比特 率 。 
应 用 可 以 设置 和 更 新 媒体 约束 (比如 ， 视 频 的 解析 度 、 帧 速率 ， 等 等 )， 剩 下 的 事 交 
给 引擎 就 好 了 一 一 这 一 块 很 简单 。 
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可 惜 的 是 ， 对 于 传输 任意 数据 的 DataCchannel 而 言 就 没有 那么 简单 了 。 与 WebSocket 
类 似 ，DataChannel API 可 以 接收 二 进 制 或 UTF-8 编码 的 应 用 数据 ， 但 它 不 能 压缩 
数据 : 优化 二 进 制 净 荷 和 压缩 UTF-8 数据 是 WebRTC 应 用 的 事 。 





此 外 ，Websocket 运行 在 可 靠 有 序 的 传输 协议 之 上 ， 而 WebRTC 应 用 必须 考虑 UDP、 
DTLS 和 SCTP 协议 产生 的 额外 开销 ， 以 及 在 部 分 可 靠 的 连接 上 交付 数据 的 各 种 问 
题 (参见 18.6.3 节 “ 部 分 可 靠 交 付 与 消息 大 小 ”)。 
Fe 

WebSocket 有 一 个 协议 扩展 ， 支 持 对 传输 数据 的 自动 压缩 。 然 而 ，WebRTC 
心 没有 类 似 的 扩展 。 因 此 ， 应 用 提供 什么 消息 ， 它 就 传输 什么 消息 。 


如 


0 


18.8 性 能 检查 表 

端 到 端的 架构 对 应 用 设计 提出 了 独特 的 挑战 。 直 接 、 一 对 一 的 通信 相对 简单 ， 而 参 
与 端 越 多 ， 问 题 就 越 复 杂 ， 至 少 对 性 能 来 说 如 此 。 最 后 ， 我 们 给 出 有 助 于 提高 端 到 
端 WebRTC 应 用 性 能 的 一 些 注意 事项 。 














。 发 信服 务 
4 使 用 低 延 迟 传输 机 制 ; 
* 提供 足够 的 容量 ; 
* 建立 连接 后 ， 考 虑 使 用 DataChannet 发 信 。 
。 防火 墙 和 NAIT 穿 越 
+ 初始 化 RTCPeerConnection 时 提供 STUN 服务 器 ， 
4 尽 可 能 使 用 增 量 ICE， 虽 然 发 信 次 数 多 ， 但 建立 连接 速度 快 ; 
* 提供 STUN 服务 器 ， 以 备 端 到 端 连接 失败 后 转发 数据 
4 预计 并 保证 TURN 转发 时 容量 足够 用 。 
。 数据 分 发 
4 对 于 大 型 多 方 通信 ， 考 虑 使 用 超级 节点 或 专用 的 中 间 设 备 ; 
4 中间 设备 在 转发 数据 前 ， 考 虑 先 对 其 进行 优化 或 压缩 。 
。 数据 效率 
* 对 音频 和 视频 流 指 定 适当 的 媒体 约束 ，; 
。 优化 通过 DataChannel 发 送 的 二 进 制 净 荷 ; 
4 考虑 压缩 通过 DataChannel 发 送 的 UTF-8 数据 ， 
+ 监控 DataChannel 缓冲 数据 的 量 ， 同 时 注意 适应 网 络 条 件 变化 。 





ES 
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。 交付 及 可 靠 性 
4 使 用 乱 序 交 付 避 免 队 首 阻 塞 ; 
。 如 有 果 使 用 有 序 交 付 ， 把 消息 大 小 控制 到 最 小 ， 以 降低 队 首 阻塞 的 影响 ， 
4 发 送 小 消息 (<1150 字 节 ) ， 以 便 将 分 段 应 用 消息 造成 的 丢 包 损失 降 至 最 低 ; 
4 对 部 分 可 靠 交 付 ， 设 置 适 当 的 重 传 次 数 和 超时 间隔 ;“ 正 确 的 ”设置 取决 于 消 
息 大 小 、 应 用 数据 类 型 和 端 与 端 之 间 的 延迟 。 
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大 于 封面 


本 书 封面 上 的 动物 是 马达 加 斯 加 融 雇 〈( 融 属 小 应 ) 。 这 种 融 应 主要 生活 在 科 摩 罗 和 群岛 
(位 于 马达 加 斯 加 北面 和 非洲 大 陆 东 南面 之 间 的 印度 洋 中 ) 和 马达 加 斯 加 岛 ， 由 于 生 
存 环 境 缩 小 或 遭受 破坏 ， 总 量 不 断 减少 。 最 近 发 现 这 种 吏 认 的 数量 比 原来 想象 得 还 
要 少 ， 它 们 小 群 散居 于 岛 上 各 处 ， 每 群 大 约 250~500 只 成 年 个 体 。 


在 马达 加 斯 加 岛 上 的 湿地 附近 ， 植 被 环绕 的 湖泊 、 沼 泽 、 滨 海 湿地 和 水 田 ， 是 这 种 
台 谭 最 常 出 没 的 捕食 场所 。 它 们 主要 猎 食 小 型 无 奉 椎 动物 和 昆虫 ， 包 括 小 型 鸟 、 蛇 、 
蜥 蝎 、 鼠 类 和 家 禽 。 捕 食 家 禽 的 习性 (数量 只 占 总 捕食 量 的 1%)， 导 臻 当地 居民 对 
它们 大 开 杀 戒 。 


每 年 的 枯 水 季 节 (8 月 末 及 9 月) 是 这 种 更 谭 的 繁殖 季节 。 雨 季 开 始 的 时 候 ， 锋 化 
( 约 32~34 天) 已 经 结束 ， 接 下 来 难 雇 的 丰 羽 期 大 约 为 42~45 天 。 然 而 ， 这 种 吏 谭 
的 繁殖 率 始 终 不 高 ， 平 均 每 是 繁 殖 丰 羽 幼 认 0.9 只 ， 而 只 有 四 分 之 三 的 梨 可 以 安然 
度 过 繁殖 期 。 这 么 低 的 繁殖 率 缘 于 年 复 一 年 大 范围 的 草原 和 沼 笃 烧 划 (本 地 居民 掏 
岛 蛋 及 捅 鸟 富 也 是 一 方面 原因 )， 目 的 是 让 大 地 长 出 新 鲜 的 牧 革 和 开 昔 ,而 且 经 常 发 
生 在 吏 订 繁殖 的 季节 。 鳌 谭 繁 入 需要 安定 的 环境 ， 而 马达 加 斯 加 岛 上 的 居民 不 断 对 
土地 的 开发 利用 对 此 形成 了 威胁 。 

为 保护 这 种 鸣 认 ， 人 们 提出 了 一 些 建议 ， 包 括 进一步 调查 摸 清 这 种 偶 谱 的 具体 数量 ， 
研究 它们 的 种 群 动态 ， 取 得 关于 出 梨 率 的 准确 信息 ， 控 制 重 点 地 带 的 烧荒 行为 一 一 
特别 是 在 繁殖 季节 ， 以 及 围绕 重点 建 梨 区 域 划 定 和 建立 保护 区 。 






































本 书 封 面 的 这 张 图 片 来 自 Histoire Naturelle, Ornithologie, Bernard Direxit。 本 书 英 
文 版 封面 字体 使 用 的 是 Adobe ITC Garamond， 正 文字 体 使 用 的 是 Adobe Minion 
Pro， 标 题字 体 使 用 的 是 Adobe Myriad Condensed， 代 码 字 体 使 用 的 是 Dalton Maag 
公司 开发 的 Ubuntu Mono。 
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怎么 才能 让 上 Web 应 用 速度 快 、 效 率 高 ?本 书 为 所 有 关心 这 个 问题 的 
人 提供 了 必须 知道 的 网 络 知 识 ， 既 包括 影响 性 能 的 最 基本 因素 ， 
也 包括 那些 能 让 我 们 创造 更 强大 Web 应 用 的 重要 技术 革新 ， 比 如 
HTTP 2.0、XHR 的 改进 、 服 务 器 发 送 事 件 (SSE) 、WebSocket 和 
WebRTC 等 。 


本 书 作 者 是 世界 顶尖 的 Web 性 能 工程 师 ， 他 在 书 中 深入 浅 出 地 讲 
解 并 演示 了 针对 TCP、UDP 和 TLS 协 议 的 性 能 优化 最 佳 实践 ， 以 及 
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电子 出 版 的 时 代 已 经 来 临 ， 在 许多 出 版 界 同行 还 在 犹 移 仿 得 的 时 候 ， 图 灵 社 区 
已 经 采取 实际 行动 拥抱 这 个 出 版 业 巨变 。 相 比 纸 质 书 ， 电 子 书 具 有 许多 明显 的 
优势 。 它 不 仅 发 布 快 ， 更 新 容易 ， 而 且 尽 可 能 采用 了 彩色 图 片 〈 即 使 有 的 书 纸 
质 版 是 黑白 印刷 的 ) 。 读 者 还 可 以 方便 地 进行 搜索 、 剪 贴 、 复 制 和 打印 。 


图 灵 社区 进一步 把 传统 出 版 流程 与 电子 出 版 业务 紧密 结合 ， 目 前 已 实现 作 译 者 
网 上 交 稿 、 编 辑 网 上 审 稿 、 按 章 发 布 的 电子 出 版 模式 。 这 种 新 的 出 版 模式 ， 我 
们 称 之 为 “敏捷 出 版 ”， 它 可 以 让 读者 以 较 快 的 速度 了 解 到 国外 最 新 技术 图 书 
的 内 容 ， 弥 补 以 往 翻译 版 技术 书 “ 出 版 即 过 时 ”的 缺憾 。 同 时 ， 敏 捷 出 版 使 得 
作 、 译 、 编 、 读 的 交流 更 为 方便 ， 可 以 提前 消灭 书稿 中 的 错误 ， 最 大 程度 地 保 
证 图 书 出 版 的 质量 。 


开放 出 版 平台 


图 灵 社 区 向 读者 开放 在 线 写 作 功 能 ， 协 助 你 实现 自 出 版 的 梦想 。 你 可 以 联合 二 
三 好 友 共 同 创作 一 部 技术 参考 书 ， 以 免费 或 收费 的 形式 提供 给 读者 ， 这 极 大 地 
降低 了 出 版 的 门槛 。 成 熟 的 书稿 ， 有 机 会 入 选 出 版 计划 ， 同 时 出 版 纸 质 书 。 


图 灵 社 区 引进 出 版 的 外 文 图 书 ， 都 将 在 立项 后 马上 在 社区 公布 。 如 果 有 意 翻 译 
哪 本 图 书 ， 欢 迎 来 社区 申请 。 只 要 通过 试 译 的 考验 ， 即 可 签约 成 为 图 灵 的 译 者 。 
当然 ， 要 想 成 功 地 完成 一 本 书 的 翻译 工作 ， 是 需要 有 坚强 的 妆 力 的 。 


读者 交流 平台 


在 图 灵 社区 ， 读 者 可 以 十 分 方便 地 写作 文章 、 提 交 勘 误 、 发 表 评论 ， 以 各 种 方 
式 与 作 译 者 、 编 辑 人 员 和 其 他 读者 进行 交流 互动 。 提 交 勘 误 还 能 够 获 赠 社区 银 
子 。 欢 迎 大 家 积极 参与 社区 开展 的 访谈 、 审 读 、 评 选 等 多 种 活动 ， 赢 取 银 子 ， 
可 以 换 书 哦 ! 


